linux-kernel - Re: [patch] Give kjournald a IOPRIO_CLASS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Nov 2007 09:51:51 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"Alan D. Brunelle" <Alan.Brunelle@...com>,
	Rik van Riel <riel@...hat.com>, jens.axboe@...cle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] Give kjournald a IOPRIO_CLASS_RT io priority

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

> 
> * Andrew Morton <akpm@...ux-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@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/