Re: [benchmark] 1% performance overhead of paravirt_ops on native kernels

[Linus Torvalds <torvalds@linux-foundation.org>]

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