[lkml]   [2012]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RFC V6 0/11] Paravirtualized ticketlocks
    On 03/28/2012 08:21 PM, Raghavendra K T wrote:
    >> 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 ].

    The advantage grows with the vcpu counts and overcommit ratio. If you
    have N vcpus and M:1 overcommit, PLE has to guess from N/M queued vcpus
    while your patch knows who to wake up.

    > 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).

    I can think of two options:
    - from the PLE handler, don't wake up a vcpu that is sleeping because it
    is waiting for a kick
    - look at other sources of pause loops (I guess smp_call_function() is
    the significant source) and adjust them to use the same mechanism, and
    ask the host to disable PLE exiting.

    This can be done incrementally later.

    > 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.

    error compiling committee.c: too many arguments to function

     \ /
      Last update: 2012-03-29 12:01    [W:0.022 / U:0.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site