Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FSis under heavy write load (massive starvation)

From: Mikulas Patocka
Date: Sat Apr 28 2007 - 02:33:07 EST




On Fri, 27 Apr 2007, Linus Torvalds wrote:



On Fri, 27 Apr 2007, Mike Galbraith wrote:

As subject states, my GUI is going away for extended periods of time
when my very full and likely highly fragmented (how to find out)
filesystem is under heavy write load. While write is under way, if
amarok (mp3 player) is running, no song change will occur until write is
finished, and the GUI can go _entirely_ comatose for very long periods.
Usually, it will come back to life after write is finished, but
occasionally, a complete GUI restart is necessary.

One thing to try out (and dammit, I should make it the default now in
2.6.21) is to just make the dirty limits much lower. We've been talking
about this for ages, I think this might be the right time to do it.

Especially with lots of memory, allowing 40% of that memory to be dirty is
just insane (even if we limit it to "just" 40% of the normal memory zone.
That can be gigabytes. And no amount of IO scheduling will make it
pleasant to try to handle the situation where that much memory is dirty.

What about using different dirtypage limits for different processes?

--- i.e. every process has dirtypage activity counter, that is increased when it dirties a page and decreased over time. Compute the limit for process as some inverse of this counter --- so that processes that dirtied a lot of pages will be blocked at lower limit and processes that dirtied few pages will be blocked at higher limit.

The main problem is that if the user extracts tar archive, tar eventually blocks on writeback I/O --- O.K. But if bash attempts to write one page to .bash_history file at the same time, it blocks too --- bad, the user is annoyed.

(I don't have time to write and test it, it is just an idea --- I found these writeback lockups of the whole system annoying too)

Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/