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] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.01.0906030901460.4880@localhost.localdomain>
Date:	Wed, 3 Jun 2009 09:09:38 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
cc:	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 Wed, 3 Jun 2009, Rusty Russell wrote:
> 
> I took my standard config, and turned on AUDIT, CGROUP, all the sched options, 
> all the namespace options, profiling, markers, kprobes, relocatable kernel, 
> 1000Hz, preempt, support for every x86 variant (ie. PAE, NUMA, HIGHMEM64, 
> DISCONTIGMEM).  I turned off kernel debugging and paravirt.  Booted with 
> maxcpus=1.

Turn off HIGHMEM64G, please (and HIGHMEM4G too, for that matter - you 
can't compare it to a no-highmem case).

It's one of those options that we do to support crazy hardware, and it is 
EXTREMELY expensive (but mainly only if you actually have the hardware, ie 
you actually have more than 1GB of RAM for HIGHMEM4G - HIGHMEM64G is 
always expensive for forks, but nobody sane ever enables it).

IOW, it's not at all comparable to the other options. It's not a software 
option, it's a real hardware option that hits you not depending on whether 
you want some sw capability, but on whether you want to use memory.

Because depending on the CPU, some loads will have 25% of time spent in 
just kmap/kunmap due to TLB flushes. Yes, really. There's a reason 32-bit 
kernels are shit for 1GB+ memory.

After you've turned off HIGHMEM (or run on a sane architecture like x86-64 
that doesn't need it), re-run the benchmark, because it's interesting. But 
with HIGHMEM being different, your benchmark is totally invalid and 
pointless.

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