- Subject: Re: [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks
- From: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 07 May 2012 20:17:10 +0530
- Cc: Srivatsa Vaddagiri <vatsa@xxxxxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Greg Kroah-Hartman <gregkh@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, X86 <x86@xxxxxxxxxx>, Gleb Natapov <gleb@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Attilio Rao <attilio.rao@xxxxxxxxxx>, Virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, linux-doc@xxxxxxxxxxxxxxx, KVM <kvm@xxxxxxxxxxxxxxx>, Andi Kleen <andi@xxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Stephan Diestelhorst <stephan.diestelhorst@xxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
- In-reply-to: <4FA7D50D.email@example.com>
- Organization: IBM
- References: <firstname.lastname@example.org> <20120507082928.GI16608@gmail.com> <4FA7888F.email@example.com> <4FA7AAD8.firstname.lastname@example.org> <4FA7BABA.email@example.com> <4FA7CC05.firstname.lastname@example.org> <4FA7CCA2.email@example.com> <4FA7D06B.firstname.lastname@example.org> <20120507134611.GB5533@linux.vnet.ibm.com> <4FA7D2E5.email@example.com> <4FA7D3F7.firstname.lastname@example.org> <4FA7D50D.email@example.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
On 05/07/2012 07:28 PM, Avi Kivity wrote:
On 05/07/2012 04:53 PM, Raghavendra K T wrote:
Is the improvement so low, because PLE is interfering with the patch, or
because PLE already does a good job?
It is because PLE already does a good job (of not burning cpu). The
1-3% improvement is because, patchset knows atleast who is next to hold
lock, which is lacking in PLE.
Not good. Solving a problem in software that is already solved by
hardware? It's okay if there are no costs involved, but here we're
introducing a new ABI that we'll have to maintain for a long time.
Hmm agree that being a step ahead of mighty hardware (and just an
improvement of 1-3%) is no good for long term (where PLE is future).
Having said that, it is hard for me to resist saying :
bottleneck is somewhere else on PLE m/c and IMHO answer would be
combination of paravirt-spinlock + pv-flush-tb.
But I need to come up with good number to argue in favour of the claim.
PS: Nikunj had experimented that pv-flush tlb + paravirt-spinlock is a
win on PLE where only one of them alone could not prove the benefit.
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]