**** BEGIN LOGGING AT Mon Dec 30 02:59:58 2013 Dec 30 10:34:18 moinmaemoians **** BEGIN LOGGING AT Mon Dec 30 12:01:50 2013 Dec 30 15:56:06 sixwheeledbeast: Does ereswap support swapfile? Dec 30 15:56:39 I only have one swap partition, but I would like to use ereswap Dec 30 16:12:11 swapfile isn't working on stock maemo kernel afaik Dec 30 16:12:41 I am not using stock kernel Dec 30 16:12:52 dunno about KP Dec 30 16:13:20 even if it works, I don;t think it makes much of a sense Dec 30 16:14:13 Yeah I know Dec 30 16:15:39 I thought at least ereswap can turn off my swap partition for a minute, use swapfile, then turn on swap partition again Dec 30 16:16:07 dividing the existing 768MB swap partition into two halves should work great, it seems Nokia just used 768MB for marketing and fragmentation reasons. A system that actually is in a status where it needs 768MB swap isn't usable by any metrics anyway Dec 30 16:16:25 fragmentation would become irrelevant with reswap Dec 30 16:17:30 Well, I guess there is also that option Dec 30 16:18:37 So 389 MB enough for Maemo's swap partition? Dec 30 16:18:55 We don't really need big swap partition? Dec 30 16:19:17 well, I personally never needed 768MB Dec 30 16:19:45 I thought Maemo need bigger swap, because its lack of ram Dec 30 16:19:58 actually it's hard to get the printout that shows swap usage >400MB, since the system already came to a grinding halt Dec 30 16:21:05 I'm sorry, how do you know how much swap already used by Maemo? Dec 30 16:21:20 err, e.g. look at htop or top Dec 30 16:21:21 free? Dec 30 16:21:26 or that Dec 30 16:21:30 cat /proc/swaps? Dec 30 16:21:34 or that Dec 30 16:21:36 :) Dec 30 16:22:17 lol, I don't know free show swap usage. Dec 30 16:22:18 Silly me Dec 30 16:22:51 I only look at memory usage when use free Dec 30 16:22:55 Ok guys Dec 30 16:22:57 Thanks Dec 30 16:23:26 I will just devide my swap partition Dec 30 16:31:46 I opened the application manager and there is a list of apps for which i need to click, open the terms agreement and the click on details, and description to read about the app.... can i see th elist of apps on a web page somewhere to quickly check them ? Dec 30 16:42:24 i have installed recaller which records all calls into a folder.. the problem is those recorded voices are getting played inbetween songs with the music player Dec 30 16:42:24 any ways to avoid that ? Dec 30 16:43:18 3. My friends view the gallery often, how can i avoid showing private pictures as a part of the gallery ? Dec 30 16:49:53 damn. my *THIRD* n950 suffers from screen rot :-( Dec 30 16:56:54 :( Dec 30 16:57:40 screen rot$ Dec 30 17:00:03 ? Dec 30 17:02:58 Arkenoi: how the heck did you manage to get THREE n950? Dec 30 17:04:32 Arkenoi: I guess you found out the hard way about why N950 never went to official sales Dec 30 17:05:11 You know how some people create a 2partition on ssd, 10-20% size, and leave it unused, in order to improve ssd perform Dec 30 17:05:32 the hinge pushing hard against LCD's back, ruining it when you're not gentle and careful when opening up the kbd Dec 30 17:05:35 why I have 2g swap on uSD Dec 30 17:08:32 ShadowJK: we discussed that recently, no? the controller on SD needs to erase pages that don't have data, so they can take new data written to them. This erasing can happen async on a background task as long as there are sufficient pages already erased so a write can copy&modify the data from one page to an empty new page Dec 30 17:09:10 obviously that background erasing of empty pages depends on empty pages _existing_ Dec 30 17:10:05 otherwise worst case (when _all_ pages hold relevant data) the controller needs to read-modify-erase-write the same erasepage on flash Dec 30 17:10:42 which slows down each write to ~50ms or whatever it takes to erase a page Dec 30 17:11:07 might also be 100 or even 200ms, I can't recall Dec 30 17:11:48 I would say nothing happens in background on SD/emmc Dec 30 17:12:49 while in the long run the performance on SD can't get inproved by keeping empty pages, they nevertheless make a convenient stash of instantly writable pages that can get used up by write action, before that throttling for erase kicks in Dec 30 17:13:21 ShadowJK: I'd say when they don't do that background erasing, they are pretty dull Dec 30 17:14:26 why wouldn't they implement flash management in eactly this way? Dec 30 17:14:36 it seems obvious and natural Dec 30 17:15:42 host devices drop voltage and clock when sd is idle, so it pretty much doesn't even run at all if the host isn't actively writing/reading, no opportunity for background tasks Dec 30 17:16:02 I'm sure you know that it's not the writing of "1" bits that takes time, but the erasing of whole page to all-zeroes Dec 30 17:16:41 Sure Dec 30 17:17:08 well, then they can't continue their background task when voltage dropped. That's pretty trivial. It however doesn't defeat the original idea Dec 30 17:17:33 But the read-write-modify cycles are what hurts performance the worst Dec 30 17:18:03 hm? Dec 30 17:21:24 the OS may write to several sectors on same erasepage. During that the SD can write to that erasepage without erasing it, and in background can erase "unused" erasepages. The very moment the OS wants to write a 0 to a bit that previously had a 1, the controller on SD will need to do a read-modify-write action and use an erased erasepage as destination for that. Same moment the controller schedules a deferred page-erase on the original, Dec 30 17:21:25 now unused, erasepage Dec 30 17:22:06 For example, host writes a tiny file to ext3, 4k written for tiny file, 4k to journal, 4k to ext3 metadata. 3 places in different locations. The first 4k gets written to a page in a newly erased block, when the next request comes in, the SD controller has to "close" the current block, so it reads in 4M-4k from the old block, writes it to its new block, and proceeds on with the second of the 3 4k requests Dec 30 17:22:20 this is what happens in practice on most SDs Dec 30 17:23:09 This describes most Kingston cards actually Dec 30 17:23:29 whatever happens in practice, the controller can always follow the "erase pages in background" policy Dec 30 17:23:33 while high-end cards are able to keep 8-12 open simultaneously Dec 30 17:24:08 sure, but it's the 4M read-modify-write that hurts more than erases.. Dec 30 17:24:26 I seriously doubt that Dec 30 17:24:37 it's known that erase takes AGES Dec 30 17:24:49 while write is relatively fast compared to that Dec 30 17:25:07 Well it's a factor of 2 or 3 Dec 30 17:25:42 While read-modify-write write amplification is a factor 1000 speed difference Dec 30 17:26:11 and actually it doesn't matter how much the erase hurts, since you can not compensate the one with the other. When you can avoid sync erase, you will do it Dec 30 17:27:13 and what you tell about your read-modify-write is actually exactly the problem that write takes an erased page Dec 30 17:27:28 otherwise you can't write modified content Dec 30 17:28:30 The amount of "half erased/written" blocks a sd can keep track of is a major influence on speed Dec 30 17:28:45 and since your unused partition reserves some erase pages for unused, it speeds up exactly those read-modify-([no]erase)-write cycles Dec 30 17:29:26 It helps the kernel more really :) Dec 30 17:29:31 there's no such thing like a half-erased erasepage Dec 30 17:29:41 erasing a page is a parallel process Dec 30 17:29:43 partially written to Dec 30 17:30:06 Some cards can deal with two sequential write streams, some can't Dec 30 17:30:18 maybe Dec 30 17:30:28 I don't see how that contrdict what I said Dec 30 17:31:04 the net effect, however, is that non-sequential writes are horribly slow, and sequential writes are fast Dec 30 17:32:04 and basically a controller doesn't need at all keep track of write fill of a page. It just needs to check if modify changed a bit from 1 to 0, which qualifies for a copy from old to new empty erasepage Dec 30 17:33:50 unless you use a layer above that to tak invalid sectors and use a next sector in same hash chain that may or may not be on same erasepage. But even then the basic principle on lowest level still stays unchanged and applies Dec 30 17:34:05 s/tak /tag / Dec 30 17:34:07 DocScrutinizer05 meant: unless you use a layer above that to tag invalid sectors and use a next sector in same hash chain that may or may not be on same erasepage. But even then the basic principle on lowest level still stays unchanged and applies Dec 30 17:34:46 Maemo kernel's swapout tries to write sequentially, it basically checks swap area for free space, sets a pointer to start of biggest continous chunk of free space, and writes sequentially into that chunk until it reaches the end, and then looks for another free chunk. With time the data gets spread out almost uniformly across the swap area, so the free area becomes smaller and smaller. Each time crossing an erase block boundary costs anout the same in terms of Dec 30 17:34:52 performance penalty, and it will be doing it much more often when it only had fragmented little spaces to write into Dec 30 17:35:37 With a huge swap partition but same 120-180M or so swapped out, the space in between occupied sectors grows larger, and it doesn't cross erase page boundaries as often Dec 30 17:35:49 yes, sure Dec 30 17:36:33 but how is that related to flash controller now? Dec 30 17:37:03 and particularly to keeping an unused partition to speed up stuff Dec 30 17:37:18 If it was as capable as a full SSD, it wouldn't matter in which order host wrote stuff Dec 30 17:37:48 errr, mhm Dec 30 17:38:40 Proper SSDs like Intel's 3700 reorders everything, constantly. :-) Dec 30 17:39:19 sorry, can't parse that Dec 30 17:39:32 aah, yep, can Dec 30 17:40:13 Internally they work almost like maemo swapout, except they gc when stuff gets fragmented. And like maemo kernel swapout, the less actual data, the easier time it has to gc and reorder Dec 30 17:40:31 maybe they reorder everything, constantly. How would I even know? I however would think it would be silly to do additional writes and page erases just to reorder something Dec 30 17:41:38 I fail to remember what we're discussing about Dec 30 17:42:11 I suggested that a user shall split his swap into two equal halves as maemo never uses 768MB anyway Dec 30 17:42:25 and I think that's been a correct advice Dec 30 17:43:18 I'm just saying with huge swap partition, swap fragmentation effects become minimal enough there's no noticeable benefit to swapoff/swapon Dec 30 17:43:38 while the initial statement of this discussion seems [2013-12-30 18:05:11] You know how some people create a 2partition on ssd, 10-20% size, and leave it unused, in order to improve ssd perform Dec 30 17:44:22 which, on a second thought, I seem to have problems to parse correctly Dec 30 17:44:45 I don't know how they do that Dec 30 17:45:43 but I guess it's done to give the flash controller some headroom to do page copy and background erase Dec 30 17:45:58 I found it interesting, that people independent of myself use the same method as I do with swap, to help the SSD controller maintain performance Dec 30 17:46:50 But then, the ssd controller and the maemo kernel swapout are operating with similar constraints, so it shouldn't be too surprising that similar tricks help both Dec 30 17:48:53 Most USB3 flash keys illustrate the constraints beautifully. 100 megabytes/sec write speed for sequential writes, 0.01 megabyte/sec for nonsequential writing :-) Dec 30 17:49:39 watching a defragmentizer with graphical progress display doing its job on a disl fille at 75% and a disk filled at 98% gives you an instant idea why it helps to keep some space unused on storage Dec 30 17:50:00 (Except "Sandisk Extreme", they put an SSD inside it, and it eats 500mA of current) Dec 30 17:50:36 s/disl fille/disk filled/ Dec 30 17:50:36 DocScrutinizer05 meant: watching a defragmentizer with graphical progress display doing its job on a disk filled at 75% and a disk filled at 98% gives you an instant idea why it helps to keep some space unused on storage Dec 30 18:00:00 (([2013-12-30 18:43:18] I'm just saying with huge swap partition, swap fragmentation effects become minimal enough there's no noticeable benefit to swapoff/swapon)) Wasn't it you who shown impressive diagrams about fragmentation kicking in after all available swap space been written once sequentially? Dec 30 18:00:48 and those diagrams didn't look like they want to suggest that increasing swap size could fundamentally change that situation Dec 30 18:01:49 it just takes longer until all available swap got used one time and this swap "filled up" with random data fragments cluttered all over the place Dec 30 18:03:31 Imagine 128M swap in use, worst case fragmentation of that 128M divided into 4k pieces and spread uniformly across the swapspace. If the swapspace is 256M big, that would mean worst case fragmentation is 4k free, 4k used, interleaved across entire device. With 1 gig swapspace, the situation improves to 4k pieces interleaved with 16k free Dec 30 18:03:58 and when the swap daemon want to reuse a freed slot that previously been used for storing some data, this is a modify on the erasepage and thus needs a page erase and page copy Dec 30 18:04:17 yes Dec 30 18:04:47 hm, would be interesting to make the kernel provide statistics on this :-) Dec 30 18:12:00 btw the "problem" is that SD is a persistent storage. There's basically never a situation of a "virgin" storage section, unless you use those special new commands that tell the controller to simply erase and leave *empty* the rest of the erasepage Dec 30 18:12:48 otherwise each erased page will inherit all the obsolete garbage of its ancestor, on read-modify-copywrite Dec 30 18:13:40 since the flash jas no idea which of the data blocks are considered "free" and which contain valid swap data Dec 30 18:14:05 considered by the swapd for example, that is Dec 30 18:15:04 thus the whole "fragmentation" actually only happens in swapd's RAM based allocation table Dec 30 18:15:25 while flash/SD always is "fragmented" Dec 30 18:16:08 afer a certain timespan of usage, with sufficient IO Dec 30 18:16:59 nd I guess not even a mkfs or other format program usually will fix that flash fragmentation, unless it's a specialized flash formatter Dec 30 18:18:38 For simplicity, I always consider SD fragmented and having only one block it can erase Dec 30 18:19:43 I honestly wonder if writing all zeroes to flash would help Dec 30 18:20:19 when controller is smart (and doesn't work erase-to-ones) it might actually help a lot with write speed Dec 30 18:22:07 I have cards where it helps Dec 30 18:22:22 But the speed boost is pretty short lived Dec 30 18:23:02 I also have cards where writing anything at all sequentially gives boost to future random write :-) Dec 30 18:25:19 Those cards typically have a small log-structured SLC cache or "journal" internally, small writes go into its cache, big writes blows away the cache and leaves it free Dec 30 18:26:14 It's obviously empty when new, and its size seems to be carefully sized to match the workload presented by running crystaldiskmark, a popular disk benchmark, with the default settings Dec 30 18:26:32 second run of crystaldiskmark gives entirely different and worse results :D Dec 30 18:49:20 Hi guys, long time no see! Dec 30 18:49:31 hai Dec 30 18:49:57 hai Dec 30 18:52:18 Been a bit busy and were not able to play and use my N900, hope I haven't missed some fun Dec 30 18:54:34 Saw that MCE is REed, anymore big news? Dec 30 18:55:18 Just the headlines, I can find the rest myself ^^ Dec 30 19:14:07 * ShadowJK reads tmo threads from 2012 Dec 30 19:14:19 I guess 2010 or 2011 was last time I read tmo Dec 30 19:16:17 * sixwheeledbeast wonders why sLumPia was asking me about ereswap. Dec 30 19:18:40 MrPingu: hi! Dec 30 19:19:29 http://talk.maemo.org/showthread.php?t=91142 Dec 30 19:19:34 MrPingu: ^^^ Dec 30 19:21:04 That's some interesting project. Dec 30 19:24:34 also #neo900 :) Dec 30 19:24:37 Seems I need to plant another money-tree... Dec 30 19:24:51 :P Dec 30 19:38:30 does anyone else has two battery icons after the latest cssu update? Dec 30 19:43:17 anYc, do you have advanced power installed? Dec 30 19:47:26 hm, I think yes Dec 30 19:52:02 Uninstall that ;) Dec 30 19:52:22 The new batteryicon give the same information AFAIK Dec 30 19:58:24 okay, I'll try that, thanks :) Dec 30 20:00:38 anYc: You're welcome **** ENDING LOGGING AT Tue Dec 31 02:59:58 2013