lkml.org 
[lkml]   [2012]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC V6 0/11] Paravirtualized ticketlocks
    On 03/28/2012 09:39 PM, Alan Meadows wrote:
    > I am happy to see this issue receiving some attention and second the
    > wish to see these patches be considered for further review and inclusion
    > in an upcoming release.
    >
    > Overcommit is not as common in enterprise and single-tenant virtualized
    > environments as it is in multi-tenant environments, and frankly we have
    > been suffering.
    >
    > We have been running an early copy of these patches in our lab and in a
    > small production node sample set both on3.2.0-rc4 and 3.3.0-rc6 for over
    > two weeks now with great success. With the heavy level of vCPU:pCPU
    > overcommit required for our situation, the patches are increasing
    > performance by an _order of magnitude_ on our E5645 and E5620 systems.
    >

    Thanks Alan for the support. I feel timing of this patch was little bad
    though. (merge window)

    >
    >
    > Looks like a good baseline on which to build the KVM
    > implementation. We
    > might need some handshake to prevent interference on the host
    > side with
    > the PLE code.
    >

    I think I still missed some point in Avi's comment. I agree that PLE
    may be interfering with above patches (resulting in less performance
    advantages). but we have not seen performance degradation with the
    patches in earlier benchmarks. [ theoretically since patch has very
    slight advantage over PLE that atleast it knows who should run next ].

    So TODO in my list on this is:
    1. More analysis of performance on PLE mc.
    2. Seeing how to implement handshake to increase performance (if PLE +
    patch combination have slight negative effect).

    Sorry that, I could not do more analysis on PLE (as promised last time)
    because of machine availability.

    I 'll do some work on this and comeback. But in the meantime, I do not
    see it as blocking for next merge window.

    >
    > Avi, Thanks for reviewing. True, it is sort of equivalent to PLE on
    > non PLE machine.
    >
    > Ingo, Peter,
    > Can you please let us know if this series can be considered for next
    > merge window?
    > OR do you still have some concerns that needs addressing.
    >
    > I shall rebase patches to 3.3 and resend. (main difference would be
    > UNINLINE_SPIN_UNLOCK and jump label changes to use
    > static_key_true/false() usage instead of static_branch.)



    \
     
     \ /
      Last update: 2012-03-28 20:23    [W:4.098 / U:0.420 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site