Re: [patch] Give kjournald a IOPRIO_CLASS_RT io priority

[Arjan van de Ven <arjan@infradead.org>]

On Wed, 14 Nov 2007 18:18:05 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > ooh, more performance testing.  Thanks
> > 
> > >     * The overwriter task (on an 8GiB file), average over 10 runs:
> > >           o 2.6.24 - 300.88226 seconds
> > >           o 2.6.24 + Arjan's patch - 403.85505 seconds
> > > 
> > >     * The read-a-different-kernel-tree task, average over 10 runs:
> > >           o 2.6.24 - 46.8145945549 seconds
> > >           o 2.6.24 + Arjan's patch - 39.6430601119 seconds
> > > 
> > >     * The large-linear-read task (on an 8GiB file), average over
> > > 10 runs: o 2.6.24 - 290.32522 seconds
> > >           o 2.6.24 + Arjan's patch - 386.34860 seconds
> > 
> > These are *large* differences, making this a very signifcant
> > patch. Much care is needed now.
> 
> and the numbers suggest it's mostly a severe performance regression. 
> That's not what i have expected - ho hum. Apologies for my earlier 
> "please merge it already!" whining.

that's.. not automatic; it depends on what the right thing is :-(
What for sure changes is that who gets to do IO changes. Some of the
tests we ran internally (we didn't publish yet because we saw REALLY
large variations for most of them even without any patch) show for
example that "dbench" got slower. But.. dbench gets slower when things
get more fair, and faster when things get unfair. What conclusion you
draw out of that is a whole different matter and depends on exactly
what the test is doing, and what is the right thing for the OS to do in
terms of who gets to do the IO.

THis makes the patch more tricky than the one line change suggests, and
this is also why I haven't published a ton of data yet; it's hard to
get useful tests for this (and the variation of the 2.6.23+ kernels
makes it even harder to do anything meaningful ;-( )


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org