Kolivas Pushes New Kernel Responsiveness Patches

[arjan_intel]

Thanks for your attention. I sent you link via PM to original image same time, but it's easy to miss it, because message notifications sucks a little at Phoronix

yeah I missed it thanks

looks like there are 2 things going on;
the VM is really busy, as well as the disk writeback threads. Based on the SVG it looks like the VM indeed swaps some stuff out (bigger delays), but once in a while, the writeback threads are so active that the CPU gets starved and you get scheduler delays of about 5 msec. (This is not per se the fault of the scheduler; with 2 logical cpus, and 3 tasks, one of the three will have to wait by definition)

it's a tough situation with not very many tunables, but you could try to bump

/proc/sys/vm/dirty_ratio and /proc/sys/vm/dirty_background_ratio to 50 and 70 respectively, and see if that helps
alternative try 5 and 10 as values
(this tunable sort of can go both ways)

[syler2000]

Proposed structure fix

btw, @arjan_intel, there is an I/O scheduler called BFS usually bundled together with the BFS process scheduler (at least in the ppa), so when people just say BFS, I would imagine they instrinsically mean BFQ coz BFS is most advertised,just my 2cts

Onto the proposal, would it be possible to migrate the niceness adjustments (process/io) to the userspace "servers" e.g. X.org (or even WMs) and sound servers e.g. pulseaudio/jack, thereby making it dynamic (not having to adjust manually at the terminal wen thins are unresponsive)?? Since it is these servers which know which processes need to be interactive (focused -> X, playing music -> pulseaudio), they would dynamically renice the processes (its naive to assume the processes would only require one nice level throughout its lifetime as usage patterns change, unless ofcourse its a server).

My (ad hoc) analysis leads me to conclude that the problem people are experiencing is due to the systems' inability to adapt to their usage patterns e.g.,I use eclipse for some heavy duty projects; the system becomes unresponsive when I am browsing with firefox and the java garbage collector (for eclipse) kicks in. Since both these processes are the same nice level, the schedulers (I/O and process, regardless CFQ/CFS & BFS/BFQ) dont know which to pioritize and firefox gets starved (even though its latency sensitive as I'm using it) so as to satisfy eclipse (which in in the background and I dont care much if it GCs in the fastese possible time). Although the problem is slightly mitigated by BFS/BFQ.

The above proposal would solve also the common problem whereby copying a large file strangles the system and offers a balance between raw throughput (what the server crowd want) and responsiveness to active processes (for desktop users) i.e. if dolphin is in focus and copying large files, it is given process & i/o priority and hence copys fast, but when it loses focus to another app, say a browser, the Xserver/kwin (technical?) would modify dolphin's niceness (process & io) reducing its priority at the same time empowering the new focused/active app e.g. browser -> btw, modern WMs have sophisticated window management (e.g. alt-tab stack), which can be used for niceness calculation ; this would work so long as the schedulers enforce the new nices. Therefore,copys would take longer if u are using the desktop actively,and would be fast (high throughput) if not.

Ever noticed how copys in windows take longer when using the PC (but u never really get annoyed as you can play solitare in between)??

[syler2000]

Sorry, BFQ is the i/o scheduler, not BFS (the process scheduler)

[drees]

You should try the latest kernel. I can't remember which kernel has it (2.6.32 or 2.6.33) but there's a change in there that should significantly improve IO read latencies under heavy write loads.

Kernel Newbies came back up, found the change, it's in 2.6.32:

CFQ low latency mode

[kraftman]

it's a tough situation with not very many tunables, but you could try to bump

/proc/sys/vm/dirty_ratio and /proc/sys/vm/dirty_background_ratio to 50 and 70 respectively, and see if that helps
alternative try 5 and 10 as values
(this tunable sort of can go both ways)

It seems it was little better with 5 and 10 as values - unresponsiveness began later and it was shorter, but maybe this is not a rule. It's still not what it should be

[arjan_intel]

It seems it was little better with 5 and 10 as values - unresponsiveness began later and it was shorter, but maybe this is not a rule. It's still not what it should be

another thing to look at is the value in
/sys/block/sda/queue/max_sectors_kb

lower values hurt throughput a bit, but increase interactivity a lot.

64Kb is often a sweetspot

[RealNC]

Kernel Newbies came back up, found the change, it's in 2.6.32:

CFQ low latency mode

It didn't improve anything here. X11 (or KDE?) still freezes completely for periods that can span several seconds when copying large files, especially when source and destination are the same disk.

[kraftman]

another thing to look at is the value in
/sys/block/sda/queue/max_sectors_kb

lower values hurt throughput a bit, but increase interactivity a lot.

64Kb is often a sweetspot

Sadly, this didn't help I also tried your previous suggestions with this one, but problem is still present.

[squirrl]

I've seen the behavior in Windows 7 64bit. In fact I am starting to believe that 64bit is plagued with problems. I speculate that developers just don't understand how to problem for 64bit yet. Perhaps it could even be just the AMD processors. I unlocked an extra core on my processor. I noticed the system was more responsive when I kept the core locked (Windows / Linux) in the 64bit environment.

1. Has anyone with IA64 had any problems?
2. If you have AMD64, have you unlocked a locked core?
3. Sun and DEC have had 64bit operating systems for years. Anyone with experience under those environments got any input?

[squirrl]

how to problem should be program, administration should increase the timeout on changes to 5 minutes.