From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Marcelo Tosatti <mtosatti@redhat.com>, X86 <x86@kernel.org>,
Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
Attilio Rao <attilio.rao@citrix.com>,
Virtualization <virtualization@lists.linux-foundation.org>,
Xen Devel <xen-devel@lists.xensource.com>,
linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas Gl
Subject: Re: [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks
Date: Wed, 30 May 2012 16:56:12 +0530 [thread overview]
Message-ID: <4FC603D4.20107@linux.vnet.ibm.com> (raw)
In-Reply-To: <4FB31CA4.5070908@linux.vnet.ibm.com>
On 05/16/2012 08:49 AM, Raghavendra K T wrote:
> On 05/14/2012 12:15 AM, Raghavendra K T wrote:
>> On 05/07/2012 08:22 PM, Avi Kivity wrote:
>>
>> I could not come with pv-flush results (also Nikunj had clarified that
>> the result was on NOn PLE
>>
>>> I'd like to see those numbers, then.
>>>
>>> Ingo, please hold on the kvm-specific patches, meanwhile.
[...]
> To summarise,
> with 32 vcpu guest with nr thread=32 we get around 27% improvement. In
> very low/undercommitted systems we may see very small improvement or
> small acceptable degradation ( which it deserves).
>
For large guests, current value SPIN_THRESHOLD, along with ple_window
needed some of research/experiment.
[Thanks to Jeremy/Nikunj for inputs and help in result analysis ]
I started with debugfs spinlock/histograms, and ran experiments with 32,
64 vcpu guests for spin threshold of 2k, 4k, 8k, 16k, and 32k with
1vm/2vm/4vm for kernbench, sysbench, ebizzy, hackbench.
[ spinlock/histogram gives logarithmic view of lockwait times ]
machine: PLE machine with 32 cores.
Here is the result summary.
The summary includes 2 part,
(1) %improvement w.r.t 2K spin threshold,
(2) improvement w.r.t sum of histogram numbers in debugfs (that gives
rough indication of contention/cpu time wasted)
For e.g 98% for 4k threshold kbench 1 vm would imply, there is a 98%
reduction in sigma(histogram values) compared to 2k case
Result for 32 vcpu guest
==========================
+----------------+-----------+-----------+-----------+-----------+
| Base-2k | 4k | 8k | 16k | 32k |
+----------------+-----------+-----------+-----------+-----------+
| kbench-1vm | 44 | 50 | 46 | 41 |
| SPINHisto-1vm | 98 | 99 | 99 | 99 |
| kbench-2vm | 25 | 45 | 49 | 45 |
| SPINHisto-2vm | 31 | 91 | 99 | 99 |
| kbench-4vm | -13 | -27 | -2 | -4 |
| SPINHisto-4vm | 29 | 66 | 95 | 99 |
+----------------+-----------+-----------+-----------+-----------+
| ebizzy-1vm | 954 | 942 | 913 | 915 |
| SPINHisto-1vm | 96 | 99 | 99 | 99 |
| ebizzy-2vm | 158 | 135 | 123 | 106 |
| SPINHisto-2vm | 90 | 98 | 99 | 99 |
| ebizzy-4vm | -13 | -28 | -33 | -37 |
| SPINHisto-4vm | 83 | 98 | 99 | 99 |
+----------------+-----------+-----------+-----------+-----------+
| hbench-1vm | 48 | 56 | 52 | 64 |
| SPINHisto-1vm | 92 | 95 | 99 | 99 |
| hbench-2vm | 32 | 40 | 39 | 21 |
| SPINHisto-2vm | 74 | 96 | 99 | 99 |
| hbench-4vm | 27 | 15 | 3 | -57 |
| SPINHisto-4vm | 68 | 88 | 94 | 97 |
+----------------+-----------+-----------+-----------+-----------+
| sysbnch-1vm | 0 | 0 | 1 | 0 |
| SPINHisto-1vm | 76 | 98 | 99 | 99 |
| sysbnch-2vm | -1 | 3 | -1 | -4 |
| SPINHisto-2vm | 82 | 94 | 96 | 99 |
| sysbnch-4vm | 0 | -2 | -8 | -14 |
| SPINHisto-4vm | 57 | 79 | 88 | 95 |
+----------------+-----------+-----------+-----------+-----------+
result for 64 vcpu guest
=========================
+----------------+-----------+-----------+-----------+-----------+
| Base-2k | 4k | 8k | 16k | 32k |
+----------------+-----------+-----------+-----------+-----------+
| kbench-1vm | 1 | -11 | -25 | 31 |
| SPINHisto-1vm | 3 | 10 | 47 | 99 |
| kbench-2vm | 15 | -9 | -66 | -15 |
| SPINHisto-2vm | 2 | 11 | 19 | 90 |
+----------------+-----------+-----------+-----------+-----------+
| ebizzy-1vm | 784 | 1097 | 978 | 930 |
| SPINHisto-1vm | 74 | 97 | 98 | 99 |
| ebizzy-2vm | 43 | 48 | 56 | 32 |
| SPINHisto-2vm | 58 | 93 | 97 | 98 |
+----------------+-----------+-----------+-----------+-----------+
| hbench-1vm | 8 | 55 | 56 | 62 |
| SPINHisto-1vm | 18 | 69 | 96 | 99 |
| hbench-2vm | 13 | -14 | -75 | -29 |
| SPINHisto-2vm | 57 | 74 | 80 | 97 |
+----------------+-----------+-----------+-----------+-----------+
| sysbnch-1vm | 9 | 11 | 15 | 10 |
| SPINHisto-1vm | 80 | 93 | 98 | 99 |
| sysbnch-2vm | 3 | 3 | 4 | 2 |
| SPINHisto-2vm | 72 | 89 | 94 | 97 |
+----------------+-----------+-----------+-----------+-----------+
From this, value around 4k-8k threshold seem to be optimal one. [ This
is amost inline with ple_window default ]
(lower the spin threshold, we would cover lesser % of spinlocks, that
would result in more halt_exit/wakeups.
[ www.xen.org/files/xensummitboston08/LHP.pdf also has good graphical
detail on covering spinlock waits ]
After 8k threshold, we see no more contention but that would mean we
have wasted lot of cpu time in busy waits.
Will get a PLE machine again, and 'll continue experimenting with
further tuning of SPIN_THRESHOLD.
WARNING: multiple messages have this Message-ID (diff)
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Marcelo Tosatti <mtosatti@redhat.com>, X86 <x86@kernel.org>,
Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
Attilio Rao <attilio.rao@citrix.com>,
Virtualization <virtualization@lists.linux-foundation.org>,
Xen Devel <xen-devel@lists.xensource.com>,
linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas Gleixner <tglx@linutronix.de>,
"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>
Subject: Re: [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks
Date: Wed, 30 May 2012 16:56:12 +0530 [thread overview]
Message-ID: <4FC603D4.20107@linux.vnet.ibm.com> (raw)
In-Reply-To: <4FB31CA4.5070908@linux.vnet.ibm.com>
On 05/16/2012 08:49 AM, Raghavendra K T wrote:
> On 05/14/2012 12:15 AM, Raghavendra K T wrote:
>> On 05/07/2012 08:22 PM, Avi Kivity wrote:
>>
>> I could not come with pv-flush results (also Nikunj had clarified that
>> the result was on NOn PLE
>>
>>> I'd like to see those numbers, then.
>>>
>>> Ingo, please hold on the kvm-specific patches, meanwhile.
[...]
> To summarise,
> with 32 vcpu guest with nr thread=32 we get around 27% improvement. In
> very low/undercommitted systems we may see very small improvement or
> small acceptable degradation ( which it deserves).
>
For large guests, current value SPIN_THRESHOLD, along with ple_window
needed some of research/experiment.
[Thanks to Jeremy/Nikunj for inputs and help in result analysis ]
I started with debugfs spinlock/histograms, and ran experiments with 32,
64 vcpu guests for spin threshold of 2k, 4k, 8k, 16k, and 32k with
1vm/2vm/4vm for kernbench, sysbench, ebizzy, hackbench.
[ spinlock/histogram gives logarithmic view of lockwait times ]
machine: PLE machine with 32 cores.
Here is the result summary.
The summary includes 2 part,
(1) %improvement w.r.t 2K spin threshold,
(2) improvement w.r.t sum of histogram numbers in debugfs (that gives
rough indication of contention/cpu time wasted)
For e.g 98% for 4k threshold kbench 1 vm would imply, there is a 98%
reduction in sigma(histogram values) compared to 2k case
Result for 32 vcpu guest
==========================
+----------------+-----------+-----------+-----------+-----------+
| Base-2k | 4k | 8k | 16k | 32k |
+----------------+-----------+-----------+-----------+-----------+
| kbench-1vm | 44 | 50 | 46 | 41 |
| SPINHisto-1vm | 98 | 99 | 99 | 99 |
| kbench-2vm | 25 | 45 | 49 | 45 |
| SPINHisto-2vm | 31 | 91 | 99 | 99 |
| kbench-4vm | -13 | -27 | -2 | -4 |
| SPINHisto-4vm | 29 | 66 | 95 | 99 |
+----------------+-----------+-----------+-----------+-----------+
| ebizzy-1vm | 954 | 942 | 913 | 915 |
| SPINHisto-1vm | 96 | 99 | 99 | 99 |
| ebizzy-2vm | 158 | 135 | 123 | 106 |
| SPINHisto-2vm | 90 | 98 | 99 | 99 |
| ebizzy-4vm | -13 | -28 | -33 | -37 |
| SPINHisto-4vm | 83 | 98 | 99 | 99 |
+----------------+-----------+-----------+-----------+-----------+
| hbench-1vm | 48 | 56 | 52 | 64 |
| SPINHisto-1vm | 92 | 95 | 99 | 99 |
| hbench-2vm | 32 | 40 | 39 | 21 |
| SPINHisto-2vm | 74 | 96 | 99 | 99 |
| hbench-4vm | 27 | 15 | 3 | -57 |
| SPINHisto-4vm | 68 | 88 | 94 | 97 |
+----------------+-----------+-----------+-----------+-----------+
| sysbnch-1vm | 0 | 0 | 1 | 0 |
| SPINHisto-1vm | 76 | 98 | 99 | 99 |
| sysbnch-2vm | -1 | 3 | -1 | -4 |
| SPINHisto-2vm | 82 | 94 | 96 | 99 |
| sysbnch-4vm | 0 | -2 | -8 | -14 |
| SPINHisto-4vm | 57 | 79 | 88 | 95 |
+----------------+-----------+-----------+-----------+-----------+
result for 64 vcpu guest
=========================
+----------------+-----------+-----------+-----------+-----------+
| Base-2k | 4k | 8k | 16k | 32k |
+----------------+-----------+-----------+-----------+-----------+
| kbench-1vm | 1 | -11 | -25 | 31 |
| SPINHisto-1vm | 3 | 10 | 47 | 99 |
| kbench-2vm | 15 | -9 | -66 | -15 |
| SPINHisto-2vm | 2 | 11 | 19 | 90 |
+----------------+-----------+-----------+-----------+-----------+
| ebizzy-1vm | 784 | 1097 | 978 | 930 |
| SPINHisto-1vm | 74 | 97 | 98 | 99 |
| ebizzy-2vm | 43 | 48 | 56 | 32 |
| SPINHisto-2vm | 58 | 93 | 97 | 98 |
+----------------+-----------+-----------+-----------+-----------+
| hbench-1vm | 8 | 55 | 56 | 62 |
| SPINHisto-1vm | 18 | 69 | 96 | 99 |
| hbench-2vm | 13 | -14 | -75 | -29 |
| SPINHisto-2vm | 57 | 74 | 80 | 97 |
+----------------+-----------+-----------+-----------+-----------+
| sysbnch-1vm | 9 | 11 | 15 | 10 |
| SPINHisto-1vm | 80 | 93 | 98 | 99 |
| sysbnch-2vm | 3 | 3 | 4 | 2 |
| SPINHisto-2vm | 72 | 89 | 94 | 97 |
+----------------+-----------+-----------+-----------+-----------+
From this, value around 4k-8k threshold seem to be optimal one. [ This
is amost inline with ple_window default ]
(lower the spin threshold, we would cover lesser % of spinlocks, that
would result in more halt_exit/wakeups.
[ www.xen.org/files/xensummitboston08/LHP.pdf also has good graphical
detail on covering spinlock waits ]
After 8k threshold, we see no more contention but that would mean we
have wasted lot of cpu time in busy waits.
Will get a PLE machine again, and 'll continue experimenting with
further tuning of SPIN_THRESHOLD.
WARNING: multiple messages have this Message-ID (diff)
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Marcelo Tosatti <mtosatti@redhat.com>, X86 <x86@kernel.org>,
Gleb Natapov <gleb@redhat.com>, Ingo Molnar <mingo@redhat.com>,
Attilio Rao <attilio.rao@citrix.com>,
Virtualization <virtualization@lists.linux-foundation.org>,
Xen Devel <xen-devel@lists.xensource.com>,
linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Stephan Diestelhorst <stephan.diestelhorst@amd.com>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas
Subject: Re: [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks
Date: Wed, 30 May 2012 16:56:12 +0530 [thread overview]
Message-ID: <4FC603D4.20107@linux.vnet.ibm.com> (raw)
In-Reply-To: <4FB31CA4.5070908@linux.vnet.ibm.com>
On 05/16/2012 08:49 AM, Raghavendra K T wrote:
> On 05/14/2012 12:15 AM, Raghavendra K T wrote:
>> On 05/07/2012 08:22 PM, Avi Kivity wrote:
>>
>> I could not come with pv-flush results (also Nikunj had clarified that
>> the result was on NOn PLE
>>
>>> I'd like to see those numbers, then.
>>>
>>> Ingo, please hold on the kvm-specific patches, meanwhile.
[...]
> To summarise,
> with 32 vcpu guest with nr thread=32 we get around 27% improvement. In
> very low/undercommitted systems we may see very small improvement or
> small acceptable degradation ( which it deserves).
>
For large guests, current value SPIN_THRESHOLD, along with ple_window
needed some of research/experiment.
[Thanks to Jeremy/Nikunj for inputs and help in result analysis ]
I started with debugfs spinlock/histograms, and ran experiments with 32,
64 vcpu guests for spin threshold of 2k, 4k, 8k, 16k, and 32k with
1vm/2vm/4vm for kernbench, sysbench, ebizzy, hackbench.
[ spinlock/histogram gives logarithmic view of lockwait times ]
machine: PLE machine with 32 cores.
Here is the result summary.
The summary includes 2 part,
(1) %improvement w.r.t 2K spin threshold,
(2) improvement w.r.t sum of histogram numbers in debugfs (that gives
rough indication of contention/cpu time wasted)
For e.g 98% for 4k threshold kbench 1 vm would imply, there is a 98%
reduction in sigma(histogram values) compared to 2k case
Result for 32 vcpu guest
==========================
+----------------+-----------+-----------+-----------+-----------+
| Base-2k | 4k | 8k | 16k | 32k |
+----------------+-----------+-----------+-----------+-----------+
| kbench-1vm | 44 | 50 | 46 | 41 |
| SPINHisto-1vm | 98 | 99 | 99 | 99 |
| kbench-2vm | 25 | 45 | 49 | 45 |
| SPINHisto-2vm | 31 | 91 | 99 | 99 |
| kbench-4vm | -13 | -27 | -2 | -4 |
| SPINHisto-4vm | 29 | 66 | 95 | 99 |
+----------------+-----------+-----------+-----------+-----------+
| ebizzy-1vm | 954 | 942 | 913 | 915 |
| SPINHisto-1vm | 96 | 99 | 99 | 99 |
| ebizzy-2vm | 158 | 135 | 123 | 106 |
| SPINHisto-2vm | 90 | 98 | 99 | 99 |
| ebizzy-4vm | -13 | -28 | -33 | -37 |
| SPINHisto-4vm | 83 | 98 | 99 | 99 |
+----------------+-----------+-----------+-----------+-----------+
| hbench-1vm | 48 | 56 | 52 | 64 |
| SPINHisto-1vm | 92 | 95 | 99 | 99 |
| hbench-2vm | 32 | 40 | 39 | 21 |
| SPINHisto-2vm | 74 | 96 | 99 | 99 |
| hbench-4vm | 27 | 15 | 3 | -57 |
| SPINHisto-4vm | 68 | 88 | 94 | 97 |
+----------------+-----------+-----------+-----------+-----------+
| sysbnch-1vm | 0 | 0 | 1 | 0 |
| SPINHisto-1vm | 76 | 98 | 99 | 99 |
| sysbnch-2vm | -1 | 3 | -1 | -4 |
| SPINHisto-2vm | 82 | 94 | 96 | 99 |
| sysbnch-4vm | 0 | -2 | -8 | -14 |
| SPINHisto-4vm | 57 | 79 | 88 | 95 |
+----------------+-----------+-----------+-----------+-----------+
result for 64 vcpu guest
=========================
+----------------+-----------+-----------+-----------+-----------+
| Base-2k | 4k | 8k | 16k | 32k |
+----------------+-----------+-----------+-----------+-----------+
| kbench-1vm | 1 | -11 | -25 | 31 |
| SPINHisto-1vm | 3 | 10 | 47 | 99 |
| kbench-2vm | 15 | -9 | -66 | -15 |
| SPINHisto-2vm | 2 | 11 | 19 | 90 |
+----------------+-----------+-----------+-----------+-----------+
| ebizzy-1vm | 784 | 1097 | 978 | 930 |
| SPINHisto-1vm | 74 | 97 | 98 | 99 |
| ebizzy-2vm | 43 | 48 | 56 | 32 |
| SPINHisto-2vm | 58 | 93 | 97 | 98 |
+----------------+-----------+-----------+-----------+-----------+
| hbench-1vm | 8 | 55 | 56 | 62 |
| SPINHisto-1vm | 18 | 69 | 96 | 99 |
| hbench-2vm | 13 | -14 | -75 | -29 |
| SPINHisto-2vm | 57 | 74 | 80 | 97 |
+----------------+-----------+-----------+-----------+-----------+
| sysbnch-1vm | 9 | 11 | 15 | 10 |
| SPINHisto-1vm | 80 | 93 | 98 | 99 |
| sysbnch-2vm | 3 | 3 | 4 | 2 |
| SPINHisto-2vm | 72 | 89 | 94 | 97 |
+----------------+-----------+-----------+-----------+-----------+
From this, value around 4k-8k threshold seem to be optimal one. [ This
is amost inline with ple_window default ]
(lower the spin threshold, we would cover lesser % of spinlocks, that
would result in more halt_exit/wakeups.
[ www.xen.org/files/xensummitboston08/LHP.pdf also has good graphical
detail on covering spinlock waits ]
After 8k threshold, we see no more contention but that would mean we
have wasted lot of cpu time in busy waits.
Will get a PLE machine again, and 'll continue experimenting with
further tuning of SPIN_THRESHOLD.
next prev parent reply other threads:[~2012-05-30 11:26 UTC|newest]
Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 10:06 [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks Raghavendra K T
2012-05-02 10:06 ` Raghavendra K T
2012-05-02 10:06 ` [PATCH RFC V8 1/17] x86/spinlock: Replace pv spinlocks with pv ticketlocks Raghavendra K T
2012-05-02 10:06 ` Raghavendra K T
2012-05-02 10:06 ` [PATCH RFC V8 2/17] x86/ticketlock: Don't inline _spin_unlock when using paravirt spinlocks Raghavendra K T
2012-05-02 10:06 ` Raghavendra K T
2012-05-02 10:06 ` [PATCH RFC V8 3/17] x86/ticketlock: Collapse a layer of functions Raghavendra K T
2012-05-02 10:06 ` Raghavendra K T
2012-05-02 10:07 ` [PATCH RFC V8 4/17] xen: Defer spinlock setup until boot CPU setup Raghavendra K T
2012-05-02 10:07 ` Raghavendra K T
2012-05-02 10:07 ` [PATCH RFC V8 5/17] xen/pvticketlock: Xen implementation for PV ticket locks Raghavendra K T
2012-05-02 10:07 ` Raghavendra K T
2012-05-02 10:07 ` [PATCH RFC V8 6/17] xen/pvticketlocks: Add xen_nopvspin parameter to disable xen pv ticketlocks Raghavendra K T
2012-05-02 10:07 ` Raghavendra K T
2012-05-02 10:07 ` [PATCH RFC V8 7/17] x86/pvticketlock: Use callee-save for lock_spinning Raghavendra K T
2012-05-02 10:07 ` Raghavendra K T
2012-05-02 10:07 ` [PATCH RFC V8 8/17] x86/pvticketlock: When paravirtualizing ticket locks, increment by 2 Raghavendra K T
2012-05-02 10:07 ` Raghavendra K T
2012-05-02 10:08 ` [PATCH RFC V8 9/17] Split out rate limiting from jump_label.h Raghavendra K T
2012-05-02 10:08 ` Raghavendra K T
2012-05-02 10:08 ` [PATCH RFC V8 10/17] x86/ticketlock: Add slowpath logic Raghavendra K T
2012-05-02 10:08 ` Raghavendra K T
2012-05-02 10:08 ` [PATCH RFC V8 11/17] xen/pvticketlock: Allow interrupts to be enabled while blocking Raghavendra K T
2012-05-02 10:08 ` Raghavendra K T
2012-05-02 10:08 ` [PATCH RFC V8 12/17] xen: Enable PV ticketlocks on HVM Xen Raghavendra K T
2012-05-02 10:08 ` Raghavendra K T
2012-05-02 10:08 ` [PATCH RFC V8 13/17] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks Raghavendra K T
2012-05-02 10:08 ` Raghavendra K T
2012-05-02 10:09 ` [PATCH RFC V8 14/17] kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration Raghavendra K T
2012-05-02 10:09 ` Raghavendra K T
2012-05-02 10:09 ` [PATCH RFC V8 15/17] kvm guest : Add configuration support to enable debug information for KVM Guests Raghavendra K T
2012-05-02 10:09 ` Raghavendra K T
2012-05-02 10:09 ` [PATCH RFC V8 16/17] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor Raghavendra K T
2012-05-02 10:09 ` Raghavendra K T
2012-05-02 10:09 ` [PATCH RFC V8 17/17] Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock Raghavendra K T
2012-05-02 10:09 ` Raghavendra K T
2012-05-30 11:54 ` Jan Kiszka
2012-05-30 11:54 ` Jan Kiszka
2012-05-30 13:44 ` Raghavendra K T
2012-05-30 13:44 ` Raghavendra K T
2012-05-07 8:29 ` [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks Ingo Molnar
2012-05-07 8:29 ` Ingo Molnar
2012-05-07 8:32 ` Avi Kivity
2012-05-07 8:32 ` Avi Kivity
2012-05-07 10:58 ` Raghavendra K T
2012-05-07 10:58 ` Raghavendra K T
2012-05-07 12:06 ` Avi Kivity
2012-05-07 12:06 ` Avi Kivity
2012-05-07 13:20 ` Raghavendra K T
2012-05-07 13:20 ` Raghavendra K T
2012-05-07 13:20 ` Raghavendra K T
2012-05-07 13:20 ` Raghavendra K T
2012-05-07 13:22 ` Avi Kivity
2012-05-07 13:22 ` Avi Kivity
2012-05-07 13:38 ` Raghavendra K T
2012-05-07 13:38 ` Raghavendra K T
2012-05-07 13:38 ` Raghavendra K T
2012-05-07 13:38 ` Raghavendra K T
2012-05-07 13:46 ` Srivatsa Vaddagiri
2012-05-07 13:46 ` Srivatsa Vaddagiri
2012-05-07 13:46 ` Srivatsa Vaddagiri
2012-05-07 13:46 ` Srivatsa Vaddagiri
2012-05-07 13:49 ` Avi Kivity
2012-05-07 13:49 ` Avi Kivity
2012-05-07 13:53 ` Raghavendra K T
2012-05-07 13:53 ` Raghavendra K T
2012-05-07 13:53 ` Raghavendra K T
2012-05-07 13:53 ` Raghavendra K T
2012-05-07 13:58 ` Avi Kivity
2012-05-07 13:58 ` Avi Kivity
2012-05-07 14:47 ` Raghavendra K T
2012-05-07 14:47 ` Raghavendra K T
2012-05-07 14:52 ` Avi Kivity
2012-05-07 14:52 ` Avi Kivity
2012-05-07 14:54 ` Avi Kivity
2012-05-07 14:54 ` Avi Kivity
2012-05-07 17:25 ` Ingo Molnar
2012-05-07 17:25 ` Ingo Molnar
2012-05-07 17:25 ` Ingo Molnar
2012-05-07 17:25 ` Ingo Molnar
2012-05-07 20:42 ` Thomas Gleixner
2012-05-07 20:42 ` Thomas Gleixner
2012-05-07 20:42 ` Thomas Gleixner
2012-05-07 20:42 ` Thomas Gleixner
2012-05-08 6:46 ` Nikunj A Dadhania
2012-05-08 6:46 ` Nikunj A Dadhania
2012-05-08 6:46 ` Nikunj A Dadhania
2012-05-08 6:46 ` Nikunj A Dadhania
2012-05-15 11:26 ` [Xen-devel] " Jan Beulich
2012-05-15 11:26 ` Jan Beulich
2012-05-15 11:26 ` Jan Beulich
2012-05-08 5:25 ` Raghavendra K T
2012-05-08 5:25 ` Raghavendra K T
2012-05-08 5:25 ` Raghavendra K T
2012-05-08 5:25 ` Raghavendra K T
2012-05-13 18:45 ` Raghavendra K T
2012-05-13 18:45 ` Raghavendra K T
2012-05-13 18:45 ` Raghavendra K T
2012-05-14 4:57 ` Nikunj A Dadhania
2012-05-14 4:57 ` Nikunj A Dadhania
2012-05-14 4:57 ` Nikunj A Dadhania
2012-05-14 4:57 ` Nikunj A Dadhania
2012-05-14 9:01 ` Raghavendra K T
2012-05-14 9:01 ` Raghavendra K T
2012-05-14 9:01 ` Raghavendra K T
2012-05-14 9:01 ` Raghavendra K T
2012-05-14 7:38 ` Jeremy Fitzhardinge
2012-05-14 7:38 ` Jeremy Fitzhardinge
2012-05-14 8:11 ` Raghavendra K T
2012-05-14 8:11 ` Raghavendra K T
2012-05-16 3:19 ` Raghavendra K T
2012-05-16 3:19 ` Raghavendra K T
2012-05-16 3:19 ` Raghavendra K T
2012-05-30 11:26 ` Raghavendra K T
2012-05-30 11:26 ` Raghavendra K T [this message]
2012-05-30 11:26 ` Raghavendra K T
2012-05-30 11:26 ` Raghavendra K T
2012-06-14 12:21 ` Raghavendra K T
2012-06-14 12:21 ` Raghavendra K T
2012-06-14 12:21 ` Raghavendra K T
2012-06-14 12:21 ` Raghavendra K T
2012-05-07 13:55 ` Srivatsa Vaddagiri
2012-05-07 13:55 ` Srivatsa Vaddagiri
2012-05-07 13:55 ` Srivatsa Vaddagiri
2012-05-07 23:15 ` Jeremy Fitzhardinge
2012-05-07 23:15 ` Jeremy Fitzhardinge
2012-05-08 1:13 ` Raghavendra K T
2012-05-08 1:13 ` Raghavendra K T
2012-05-08 9:08 ` Avi Kivity
2012-05-08 9:08 ` Avi Kivity
2012-05-07 13:56 ` Raghavendra K T
2012-05-07 13:56 ` Raghavendra K T
2012-05-07 13:56 ` Raghavendra K T
2012-05-07 13:56 ` Raghavendra K T
2012-05-13 17:59 ` Raghavendra K T
2012-05-13 17:59 ` Raghavendra K T
2012-05-13 17:59 ` Raghavendra K T
2012-05-13 17:59 ` Raghavendra K T
2012-05-07 8:29 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FC603D4.20107@linux.vnet.ibm.com \
--to=raghavendra.kt@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=attilio.rao@citrix.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=gregkh@suse.de \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=stephan.diestelhorst@amd.com \
--cc=torvalds@linux-foundation.org \
--cc=vatsa@linux.vnet.ibm.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.