I wanted to find something to balance out the n900 I/Os and get a consistently smooth experience. I came across the I/O queue depth parameter nr_requests which is found here:
This parameter is 128 by default. I read Zan Lynx's comment from this website:
http://stackoverflow.com/questions/3...y-is-happening

Then I read a bit more on nr_requests and found this site:
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

I changed my nr_requests to 100000 and it feels like a balanced system and things are smooth. It's like this is what was missing.

Hope it helps...and don't forget to thank me

I have tried 4000 but now I try 4 like nightfire's setting! Thanks for this!

On the N900, I think tuning it down is better, so long as you also down tune down the dirty ratio and dirty background ration... swappiness lower probably helps too.

Not sure though. I may try the significantly higher values later, see if there's a difference.

yes it is better to tune down. 4 seems to be a good value also this is a flash and ssd device so it doesn't need much readahead i think.

Careful; the larger the I/O request queue, the more likely it is you'll lose data on power loss or if your phone crashes.

nr_requests doesn't affect the amount of data cached before writing, or the duration before data gets written.

MMC/SD and usb flash drives behaves completely different than real SSDs. The emmc in n900 will do something like 8megabytes/second writing sequentially, and 30 kilobytes/second when fed random writes.

That means the better sorted requests to it are, the better throughput will be. Note I said throughput, not interactivity, which is probably what users mostly notice.

Oh how I wish we could keep this all on one thread.

It will...

I/O queues become populated after pages become eligible for flushing. So, it adds to the write delay. It's possible to have 128 writes queued up even if your dirty_expire_centisecs or dirty_background_ratio is 0, if your nr_requests is 128+.

If you lose power at that point, those writes are gone.

I myself haven't notice any loss in bandwidth switching to a queue depth of 1.

I've noticed that nr_requests at a low number like 4 or 1 sucks for me. The high number is much better, but there is no great way to know the optimal value.

My approach is that I can start at a low number like 1 and work my way up until the performance improvement isn't as much. Then stop there because the net improvement is not worth the additional risk of losing data.

At 128, you hardly have performance improvement...still have more to go to see it. I settled on 8192 for now to not have it quite so high and seems like pretty much the same as 100000. 128 is not enough for the I/O scheduler and whatever else to work with and do a good job apparently.

I told my friend who is using Android on his HTC nexus one to give it a try and he's underclocking his system now because of it