[lkml]   [2009]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [benchmark] 1% performance overhead of paravirt_ops on native kernels
    Hi Chris,

    On Tue, Jun 2, 2009 at 8:03 AM, Chris Mason <> wrote:
    >>> The best place to fix xen is in the kernel.

    On Tue, Jun 02, 2009 at 08:22:57AM -0700, Ulrich Drepper wrote:
    >> No.  The best way to fix things is _on the way into the kernel_.

    On Tue, Jun 2, 2009 at 7:20 PM, Chris Mason <> wrote:
    > It all depends on which parts are causing problems.  A 1% performance
    > hit, under a CONFIG_ that can be disabled?  If maintainers are focusing
    > on details like this for long term and active projects, we're doing
    > something very wrong.

    The fact that CONFIG_PARAVIRT can be disabled doesn't really help. As
    a matter of fact, I'd argue that one of the primary reasons
    CONFIG_SLUB regression is still there is because people can just
    disable it and use CONFIG_SLAB instead.

    So I think we have some evidence to suggest that people have less
    incentive to fix things once something is merged to the kernel. And I
    don't mean the authors of the code here but basically _everyone_
    involved in kernel development. It usually takes effort from variety
    of people to get everything ironed out because, lets face it, we can't
    expect a handful of people to test out every configuration let alone
    fix them.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-06-02 20:17    [W:0.025 / U:39.680 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site