Re: [PATCH RFC V6 0/11] Paravirtualized ticketlocks
From: Avi Kivity
Date: Thu Mar 29 2012 - 05:59:25 EST
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/