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

[Chris Mason <chris.mason@oracle.com>]

On Sat, May 30, 2009 at 12:23:30PM +0200, Ingo Molnar wrote:
> 
> * Nick Piggin <npiggin@suse.de> wrote:
> 
> > FWIW, we had to disable paravirt in our default SLES11 kernel. 
> > (admittedly this was before some of the recent improvements were 
> > made). But there are only so many 1% performance regressions you 
> > can introduce before customers won't upgrade (or vendors won't 
> > publish benchmarks with the new software).
> > 
> > But OTOH, almost any bit feature is going to cost performance. I don't
> > think this is something new (as noted with CONFIG_SECURITY). [...]
> 
> Yes in a way, but the difference is that:
> 
>  - i noted CONFIG_SECURITY as the _worst current example_. It is the
>    largest-overhead feature known to me in this area, and i 
>    benchmark the kernel a lot. CONFIG_PARAVIRT has _even more_
>    overhead so it takes the (dubious) top spot in this category.
> 
>  - CONFIG_SECURITY, in the distros where it's enabled (most of them) 
>    it is actually being relied on by the default user-space. It's 
>    being configured and every default install of the distro has a 
>    real (or at least perceived) advantage from it.
> 
> Not so with CONFIG_PARAVIRT. That feature is almost fully parasitic 
> to native environments: currently it brings no advantage on native 
> hardware _at all_ (and 95% of the users dont care about Xen).
> 
> Still it's impractical for a distro to disable it because adding a 
> separate kernel package has high costs too and PARAVIRT=y is needed 
> for the weird execution environment that Xen requires to run Linux 
> with acceptable speed.

I think all of the distros expect mainline to do a difficult balancing
act.  On the one hand we don't want any performance regressions, and on
the other hand, we need to be able to work with mainline to get the
major features that we're shipping and using every day in.

What we have here is a CONFIG_ that would be heavily used if it were
included.  It may be used as part of a separate kernel build, or it may
be used for a single kernel image.  Either way, this is something for
the distros to decide.  You're arguing to leave it out of mainline
because making a separate kernel package for it is too hard, but by
doing so forcing them to maintain the patches out of tree.  They still
have the same decision about the second package either way.

The xen developers are not dropping this code on mainline and running
away to spend the rest of their lives on the beach.  This is is a step
in long term development, and keeping it out of the kernel is making
testing and continued development much harder on the users.

I'm not suggesting we should take broken code, or that we should lower
standards just for xen.  But, expecting the xen developers to fix the 1%
hit on a very specific micro-benchmark is not a way to promote new
projects for the kernel, and it isn't a good way to convince people to
do continued development in mainline instead of in private trees.

Please reconsider.  Keeping these patches out is only making it harder
on the people that want to make them better.

-chris