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

Brice Figureau
2007-08-05T17:23:13Z

Hi,

Ingo Molnar <mingo <at> elte.hu> writes:
> * Linus Torvalds <torvalds <at> linux-foundation.org> 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
>
>[ snipped part of the bug report ]
>
> 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.

Foreword: I'm the OP of bug #7372.

I just want to say/add that:
1) I'm running the per-bdi patch since about 30 days on a master mysql server
under somewhat mild load without any adverse effect I could notice.

2) I _still_ don't get the "performances" of 2.6.17, but since that's the
better combination I could get, I think there is IMHO progress in the right
direction (to be compared to no progress since 2.6.18, that's better :-)).

To be honest, a vanilla 2.6.17 not tuned at all (ie vfs_cache_pressure and other
knobs in /proc/sys/vm like swappiness and dirty_*) is still better than any
other upcoming kernel I tested. Thus I still think 2.6.18 added a big regression
(which unfortunately I couldn't find).
Read the full bug report for any background information if needed.

Unfortunately it isn't practical to git-bisect my issue as the server is a
production server that can't be rebooted/stopped whenever I want (and since I
found workarounds of the issue...).

Thanks for showing interest in this issue.

Please CC: me on any answers as I'm not subscribed to the list.

--
Brice Figureau