lkml.org 
[lkml]   [2009]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [benchmark] 1% performance overhead of paravirt_ops on native kernels
    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



    \
     
     \ /
      Last update: 2009-06-02 16:27    [W:4.049 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site