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

    On Tue, Jun 2, 2009 at 8:03 AM, Chris Mason <chris.mason@oracle.com> 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 <chris.mason@oracle.com> 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.

    Pekka
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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