linux-kernel - Re: [benchmark] 1% performance overhead of paravirt

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]

Message-Id: <200906041652.55298.dcm@mccr.org>
Date:	Thu, 4 Jun 2009 16:52:54 -0500
From:	Dave McCracken <dcm@...r.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Rusty Russell <rusty@...tcorp.com.au>, Ingo Molnar <mingo@...e.hu>,
	Nick Piggin <npiggin@...e.de>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Avi Kivity <avi@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [benchmark] 1% performance overhead of paravirt_ops on native kernels

On Thursday 04 June 2009, Linus Torvalds wrote:
> On Thu, 4 Jun 2009, Rusty Russell wrote:
> > > Turn off HIGHMEM64G, please (and HIGHMEM4G too, for that matter - you
> > > can't compare it to a no-highmem case).
> >
> > Thanks, your point is demonstrated below.  I don't think HIGHMEM4G is
> > unreasonable for a distro tho, so I turned that on instead.
>
> Well, I agree that HIGHMEM4G is a reasonable thing to turn on.
>
> The thing I disagree with is that it's at all valid to then compare to
> some all-software feature thing. HIGHMEM doesn't expand any esoteric
> capability that some people might use - it's about regular RAM for regular
> users.

I think you're missing the point of Rusty's benchmark.  I see his exercise as 
"compare a kernel configured as a distro would vs a custom-built kernel 
configured for the exact target environment".  In that light, questions about 
the CONFIG options Rusty used should be based on whether most distros would 
use them in their stock kernels as opposed to how necessary they are.

What I see as the message of his benchmark is if you care about performance 
you should be customizing your kernel anyway.  Distro kernels are slow.  An 
option that makes the distro kernel a bit slower is no big deal since anyone 
who wants speed should already be rebuilding their kernel.

Don't get me wrong.  I think it's always a good idea to minimize any 
performance penalty, even under specific configurations.  I just think 
criticizing it because distros might enable it is a poor argument.

Dave McCracken
Oracle Corp.

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