Originally Posted by TiagoTiago

How does this compare to Swappolube?

Originally Posted by nightfire

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).

Originally Posted by Creamy Goodness

you can adjust most of these settings from swappolube, but its missing the

Code:

/proc/sys/vm/min_free_kbytes 
/sys/block/mmcblk0/queue/nr_requests
/sys/block/mmcblk1/queue/nr_requests

why couldn't you look yourself?

Originally Posted by Bratag

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

Originally Posted by nightfire

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

Originally Posted by Mentalist Traceur

Swappolube came from Hawaii's optimizations. Most of them are similar to yours, however they were more along the lines of reducing occurances of I/O in general, and reducing swapping when not necessary. Swappiness was set to 30, and a few other changes were made. dirty and dirty_background ratios were put really high, and he didn't reduce the queues... Eventually someone packaged those changes as "swappolube" as a script, then it got made into a GUI program. Anyway, the difference is hawaii's original mods aimed for a I/O less, I/O in efficient bursts approach, where as you seem to go for a I/O often, so that I/O doesn't build up.

That said, I personally have been fiddling to get my own combination of settings based on those original mods.What I personally want to see is as little swap as possible while I still have ram space, but I don't want it to zealously abandon swapping the way it would if swapping is made zero. I'll fiddle with this myself, let you know if it seems better than what I'm doing.

It seems more in line with what I've been trying to do, which is keep as little memory as possible from being forced into swap, while still allowing for swapping when it is 'needed', since the smaller queues and the smaller dirty ratios would help keep it from accumulating dirty pages.

I'm having stellarium downloading one of the more massive (8 of 9 I believe) catalogs right now over wifi, so I don't want to fiddle too much now, but I'll get back to you when I get that over with and have had time to write the changes to where I want them, and then rebooted.

Originally Posted by nightfire

We want to swap http://talk.maemo.org/images/icons/icon8.gifas much unused data out as we can (ie. X init and bootup code, shells hosting blocked scripts, etc) to free memory for stuff we care about yet don't want to swap out stuff we might want again (and in a hurry). My argument for a low swappiness factor is.. since we're under so much pressure anyway the system will not have trouble finding excuses to page out.

Originally Posted by nightfire

I would, but I'm still trying to figure out how to workaround Samba's unwavering desire to pre-allocate writes... which don't cooperate with non-sparse-file enabled filesystems like the lowly fat32.

I'll take a look at swappolube later.