Re: [PATCH 00/23] per device dirty throttling -v8

From: Ingo Molnar
Date: Sat Aug 04 2007 - 02:32:56 EST



* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Fri, 3 Aug 2007, Peter Zijlstra wrote:
> >
> > These patches aim to improve balance_dirty_pages() and directly address three
> > issues:
> > 1) inter device starvation
> > 2) stacked device deadlocks
> > 3) inter process starvation
>
> Ok, the patches certainly look pretty enough, and you fixed the only
> thing I complained about last time (naming), so as far as I'm
> concerned it's now just a matter of whether it *works* or not. I guess
> being in -mm will help somewhat, but it would be good to have people
> with several disks etc actively test this out.

There are positive reports in the never-ending "my system crawls like an
XT when copying large files" bugzilla entry:

http://bugzilla.kernel.org/show_bug.cgi?id=7372

" vfs_cache_pressure=1
TCQ nr_requests
8 128 not that bad
1 128 snappiest configuration, almost no pauses
(or unnoticable ones) "

" 1) vfs_cache_pressure at 100, 2.6.21.5+per bdi throttling patch
Result is good, not as snappier as I'd want during a large copy but
still usable. No process seems stuck for agen, but there seems to be
some short (second or subsecond) moment where everything is stuck
(like if you run a top d 0.5, the screen is not updated on a regular
basis).

2) vfs_cache_pressure at 1, 2.6.21.5+per bdi throttling patch Result
is at 2.6.17 level. It is the better combination since 2.6.17. "

" 1) I've applied the patches posted by Peter Zijlstra in comment #76
to the 2.6.21-mm2 kernel to check if it removes the problem. My
impression is that the problem is still there with those patches,
although less visible then with the clean 2.6.21 kernel. "

so the whole problem area seems to be a "perfect storm" created by a
combination of TCQ, IO scheduling and VM dirty handling weaknesses. Per
device dirty throttling is a good step forward and it makes a very
visible positive difference.

Ingo
-
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/