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 14:43:33 -0500
From:	"Alan D. Brunelle" <Alan.Brunelle@...com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	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

Arjan van de Ven wrote:
> 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 ;-( )
>
>
>   
I'd also like to point out here that the run-to-run deviation was indeed 
quite large for both the unpatched- and patched-kernels, I'll report on 
that information with the next set of results...

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