Re: Massive interactivity improvement under high I/O load!
 

Well, you lose access to whatever is swapped. Which is why you may just be very screwed. :D If/when I invest in that 32 GB class 10 MicroSD card I am hoping to acquire eventually, I will be happy to test this unmount-during-swapping scenario. Too lazy to do it with my current somewhat-small-capacity, slower ones.

Also, the above test I mentioned above while downloading catalog 8/9 was with Laptop mode on. I turned laptop mode off for this next test (catalog 9/9, significantly bigger) - while leaving the massive dirty (background) ratio values... So that combination was a bit less than ideal. Download speed was nice, but UI responsiveness ground to a halt in some moments... Hmmm, specifically, during the actual finishing of the download. It had the same horrible unresponsiveness during the previous test for about a minute or so, when it finished downloading that catalog.

So what does that tell us? Laptop mode on-off doesn't seem to effect either sustained downloading or the finalizing of the write of that file, that I could notice. By itself, however, it seems that just lowering the I/O queues, but not changing the ratios or the vfs_cache_pressure, doesn't solve the unresponsiveness problem.

On the other hand, for all I know, it does, and had this been an N900 with all values at stock, the same slowness/UI-paralysis could have lasted much longer, when downloading that big of a file and saving it, all the while having Stellarium running in the background, with real time and a decently wide viewing angle, plus twinkle for the stars enabled.

So, to sumrise, when using Stellarium's built in catalogue download, tweakings JUST the queue sizes down seems to increase download speed, but, if your dirty ratio and dirty background ratio are high, swappiness is low, you do NOT have regular pdf flush daemon wakeups enables (mine don't wake up automatically, I have both centisecs values at 0), there is still a massive slow-down when finishing the download.

My GUESS is that had I had the centisecs values set to something low, or the ratio values set to something low, both would have lessened the final slow-down as well, probably significantly, because with dirty ratio at 95 and dirty background ratio at 65, and no routine flush daemons waking up, the dirty pages built up, both in RAM and in swap, I suspect.

Speaking of which, Stellarium runs great with all star cataloges downloaded. This is the non-mobile one. The mobile one presumably does even better.

Re: Massive interactivity improvement under high I/O load!
 

According to this thread (from post 21 onwards) the default is cfq.

It should be a simple matter of "echo noop > /sys/block/mmcblk0/queue/scheduler".

Re: Massive interactivity improvement under high I/O load!
 

On the subject of swap, do take a look at the ramzez and Diablo Turbo threads. On Diablo at least, ramzswap is the single most effective way to improve responsiveness when memory-starved (which is pretty much always if you're actually using the device).

Re: Massive interactivity improvement under high I/O load!
 

i just figured out how to do this yesterday, using the tablet mode hack.
http://talk.maemo.org/showthread.php?t=69912

do you have a more elegant way of doing this or is this the same method youre using?

Re: Massive interactivity improvement under high I/O load!
 

I'm giving it a try, seems noticeably quicker right off the bat :cool:

Edit: Multitasking performance has REALLY improved. The performance increase from this is better than a 700Mhz overclock! Note: I'm also running swap-on-microSD.

Re: Massive interactivity improvement under high I/O load!
 

That's not entirely correct. flash memory has massive penalty on writing randomly to different erase pages. I planned to share a link here, but have to realize I can't find the one good one. Google might help, or ask shadowJK on #maemo IRC. Basically the point is - depending on number of buffers in MMC controller - the writing to a different erase page (wich are sized like e.g 128kb) makes the controller erase a flash-page and write the dirty internal buffer to flash, then read back to buffer the new page addressed, and finally modifies the content of buffer according to the pending IO. So for a sequence like write to 0x10000, 0x50000, 0xB0000 it makes almost no difference if the individual write IO is for 1 byte or 50kB - it's the erasing and rewriting of a whole page that takes xx milliseconds, while IO to the same erase page actually only modifies the RAM buffer in controller and takes no time at all.

AFAIK a lot of elementary stuff already is mlocked, e.g rtcom-dialer-ui

What we really need is maybe a scheduler (plus kswapd) tailored to fit the exact operation mode and capabilities of the particular flash controller

/j

Re: Massive interactivity improvement under high I/O load!
 

Tried it a few times (twice by accident, forgetting that I had swap on SD, once on purpose to test the effect), every time the system either hung or reset (can't remember which one). I don't think the system actually needs to be swapping at the moment, it's probably enough that the pages get lost.

It would be interesting to know whether the unmounting/disconnection of the SD card is done by SW or HW, and whether it can be prevented.

Re: Massive interactivity improvement under high I/O load!
 

I'd guess it's done by the MMC-driver in kernel. There's definitely no hw switching off uSD slot the hard way, but given the fact you can ruin a card by inadvertently removing it, I won't suggest to override this mechanism.

/j

Re: Massive interactivity improvement under high I/O load!
 

Yes, because we want our SD cards corrupted if yanked out before unmounting.

It IS a good idea, but only in conjunction with swap relocating
scripts, in my opinion.

Re: Massive interactivity improvement under high I/O load!
 

You answered your own question :)

I've been using SD for swap for a long time now and it makes a big improvement since it frees up eMMC i/o for other things besides swapping.

For testing the settings from this thread I moved swap back to eMMC to get a more fair comparison. If I can avoid using SD for swap I will.