Hey everyone,

I've been using my phone as a wireless media server for friends (with Samba + wifi hotspot). While it worked brilliantly for reads, writes were causing all kinds of weird issues, and absolutely destroyed interactivity on the phone itself.

Later, while copying several 400mb files from internal storage to my SD card, it actually froze, and rebooted. I suspect dsme was swapped out and couldn't respond quickly enough to avoid the watchdog.

Anyway, I sat down and thought about the problem, and set about to improve interactivity under I/O load. This is my current configuration, and I find it vastly improves responsiveness:

Quick explanation:

Generally speaking, Linux is tuned for rotating media, not flash memory. The VM and I/O schedulers try to group I/Os together in a sensible manner, to reduce disk thrashing.

Of course, it's meaningless on the n900; there is no penalty for discontinous I/O.

So what I've done is:

- Reduce the time dirty buffers and pages are allowed to remain dirty; they should be eligible for flushing almost immediately.

- Reduce the amount of VM allowed to stay dirty; I/Os block once this threshold is met.

- Increase the minimum amount of free physical memory. The kernel will always try to leave 4mb free (yes, wasted) so that large allocations can take place even under high memory pressure (without swapping). When used, the kernel prioritizes its replacement by freeing other memory (through swapping or flushing writes).

- Reduce the willingness of the system to needlessly swap. This one is somewhat contentious (no pun intended); if your phone doesn't favor maintaining cache and free memory, swap-outs can be exceptionally long, when required, to make room for things like the Phone app. However, due to the overall improvement in interactivity, I find it acceptable. I've never come close to missing a call.

- Prefer to free disk cache over program data. The onboard storage (and even microsd) is quite fast for reads, and has no rotational latency. Since we're almost always under pressure for RAM, let's prefer to keep data we know we'll need over VFS cache. Helps to prevent large files (ie. videos) from overwhelming program data.

- Set the swap page size to 256k to match the SD card or internal flash device.

- .. and finally:

The most important change was reducing (essentially eliminating) the device I/O queues. The main purpose of I/O queueing is to allow the system to make intelligent read/write decisions based on a large number of elements requested (nearly) concurrently, such as contiguous streaming of data collected across multiple writes.

This doesn't really provide any benefit for us though! There is no additional latency associated with discontinuous writes, so why let the I/O queues build up?

Reducing them to 4 causes I/Os to block, rather than queue. This means you're less likely to encounter a situation where the queue is slammed by a large background process (ie. copying a 400mb file), and something you do in the foreground requires immediate I/O to continue, because the longest you'll have to wait is 4 I/Os!

Anyway, if you want to give it a try, just paste those commands into your terminal as root.

I'd advise against making them permanent until more people try it out.

And if you're a VFS maintainer and notice an error in my logic please point it out as well!

what do you mean by causing the I/O to block, does it return a failure status on the request?

No, it forces I/O attempting processes to write out the dirty pages during their time slot, as I understand it.

So during the milliseconds-to-seconds that there's too many dirty pages, the CPU ignores I/O requests and instead spends those time slots writing out the dirty pages. If the gap between dirty_ratio and dirty_background_ratio is somewhat small, and the gap between flushes is reasonably small, it shouldn't cause too many issues on a human-perceptibility level.

I am not that knowledgeable on kernel parameters on the VM system though, so feel free to correct me, anyone who knows better.

How does this compare to Swappolube?

Never heard of swappolube...

In any case, like Mentalist Traceur said, blocking I/O doesn't result in a failure, it just means the process read()s, write()s, etc.. won't return immediately, but only once there's sufficient room in the (now very small) queue.

The benefit is that some desktop application that needs to read a config file doesn't risk ended up at queue position 100, waiting for 99 I/Os to complete, because cp, tar, or samba wasn't able to burst all those writes through (write() blocked quickly).

I've written tune-up tools. I've other parametres. U may find it interesting. What are the original values?

Thanks.. I'll check em out.

I actually don't have the original values anymore.. They were quite different, though. If anyone wants to check, just run this (root not required):

U should try ur settings with cutetube and avatar trailer hd. Looks very promising. I want to try it later.

The min_free_kbytes value is not that different from the original.

As requested. As a side point. If this does what we think it does - then the issues with transmission essentially locking up the phone (ok really slowing it down) will be mitigated to some extent.

Exactly. I'm actually able to place phone calls, browse, and launch programs while writing at 8mb/sec! It was totally unusable before.