Reply
Thread Tools
Posts: 310 | Thanked: 383 times | Joined on Jan 2010
#1
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:

Code:
    echo 3 > /proc/sys/vm/dirty_ratio
    echo 3 > /proc/sys/vm/dirty_background_ratio
    echo 100 > /proc/sys/vm/dirty_writeback_centisecs 
    echo 100 > /proc/sys/vm/dirty_expire_centisecs 
    echo 4096 > /proc/sys/vm/min_free_kbytes 
    echo 50 > /proc/sys/vm/swappiness 
    echo 200 > /proc/sys/vm/vfs_cache_pressure 
    echo 8 > /proc/sys/vm/page-cluster
    echo 4 > /sys/block/mmcblk0/queue/nr_requests
    echo 4 > /sys/block/mmcblk1/queue/nr_requests
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!

Last edited by nightfire; 2011-02-17 at 16:07.
 

The Following 93 Users Say Thank You to nightfire For This Useful Post:
-L-, abill_uk, anapospastos, ArnimS, Arrancamos, attila77, Bartus, Benson, bobh, Bundyo, cddiede, ceevee, cfh11, Char, cheve, clasificado, corduroysack, Creamy Goodness, Dark_Angel85, debernardis, elie-7, Estel, EugeneS, ezmendriz, F2thaK, fasza2, fms, frostbyte, fusi, fw190, gabby131, Gucky66, HellFlyer, Helmuth, joerg_rw, juise-, jurop88, kevloral, kinggo, kmare, kopele, ktchiu, leetnoob, Lehto, lma, Manatus, Marshall Banana, MartinK, mathiasp, mece, mehulrajput, Mentalist Traceur, mikec, moepda, mpi, mrojas, mscion, nashith, Necc, OVK, pedrolucasbp, pelago, peterleinchen, pillar, qole, rabarkar, rebhana, reinob, RobbieThe1st, saned, sbock, scribbles, stlpaul, Stonik, stopgap, Switch_, theonelaw, Tiboric, tokag, trompkins, tswindell, uppercase, uvatbc, vdx29, Venemo, wumpwoast, Xagoln, ysss, Zaerc, zero, zillertal
Posts: 1,463 | Thanked: 1,916 times | Joined on Feb 2008 @ Edmonton, AB
#2
what do you mean by causing the I/O to block, does it return a failure status on the request?
 
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#3
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.
 

The Following 4 Users Say Thank You to Mentalist Traceur For This Useful Post:
Posts: 1,522 | Thanked: 392 times | Joined on Jul 2010 @ São Paulo, Brazil
#4
How does this compare to Swappolube?
 

The Following 3 Users Say Thank You to TiagoTiago For This Useful Post:
Posts: 310 | Thanked: 383 times | Joined on Jan 2010
#5
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).
 

The Following User Says Thank You to nightfire For This Useful Post:
Banned | Posts: 358 | Thanked: 160 times | Joined on Dec 2010
#6
I've written tune-up tools. I've other parametres. U may find it interesting. What are the original values?
 
Posts: 310 | Thanked: 383 times | Joined on Jan 2010
#7
Originally Posted by epitaph View Post
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):

Code:
echo -n "dirty_ratio: " ; cat /proc/sys/vm/dirty_ratio
echo -n "dirty_background_ratio: " ; cat /proc/sys/vm/dirty_background_ratio
echo -n "dirty_writeback_centisecs: " ; cat /proc/sys/vm/dirty_writeback_centisecs 
echo -n "dirty_expire_centisecs: " ; cat /proc/sys/vm/dirty_expire_centisecs 
echo -n "min_free_kbytes: " ; cat /proc/sys/vm/min_free_kbytes 
echo -n "swappiness: " ; cat /proc/sys/vm/swappiness 
echo -n "vfs_cache_pressure: " ; cat /proc/sys/vm/vfs_cache_pressure 
echo -n "onboard_nr_requests: " ; cat /sys/block/mmcblk0/queue/nr_requests
echo -n "sd_nr_requests: " ; cat /sys/block/mmcblk1/queue/nr_requests
 
Banned | Posts: 358 | Thanked: 160 times | Joined on Dec 2010
#8
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.

Last edited by epitaph; 2011-02-17 at 04:05.
 
Posts: 2,014 | Thanked: 1,581 times | Joined on Sep 2009
#9
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.

Code:
dirty_ratio: 95

dirty_background_ratio: 60

dirty_writeback_centisecs: 0

dirty_expire_centisecs: 0

min_free_kbytes: 2039

swappiness: 30

vfs_cache_pressure: 100

onboard_nr_requests: 128

sd_nr_requests: 128
__________________
Class .. : Power Poster, Potential Coder
Humor .. : [*********] Alignment: Chaotic Evil
Patience : [***-------] Weapon(s): +2 Logic Mace
Agro ... : |*****-----] Relic(s) : G1, N900

 

The Following 2 Users Say Thank You to Bratag For This Useful Post:
Posts: 310 | Thanked: 383 times | Joined on Jan 2010
#10
Originally Posted by Bratag View Post
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.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 03:51.