From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jiannan Ouyang <ouyang@cs.pitt.edu>, Gleb Natapov <gleb@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Jeremy Fitzhardinge <jeremy@goop.org>,
x86@kernel.org, konrad.wilk@oracle.com,
"H. Peter Anvin" <hpa@zytor.com>,
pbonzini@redhat.com, linux-doc@vger.kernel.org,
"Andrew M. Theurer" <habanero@linux.vnet.ibm.com>,
xen-devel@lists.xensource.com,
Peter Zijlstra <peterz@infradead.org>,
Marcelo Tosatti <mtosatti@redhat.com>,
stefano.stabellini@eu.citrix.com, andi@firstfloor.org,
attilio.rao@citrix.com, gregkh@suse.de, agraf@suse.de,
chegu vinod <chegu_vinod@hp.com>,
torvalds@linux-foundation.org, Avi Kivity <avi.kivity@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>, KVM <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
stephan.diestelhorst@amd.com, Rik van Riel <riel@redhat.com>,
Andrew Jones <drjones@redhat.com>,
virtualization@lists.linux-foundation.org,
Srivatsa Vaddagiri <srivatsa.vaddagiri@gmail.com>
Subject: Re: [PATCH RFC V9 0/19] Paravirtualized ticket spinlocks
Date: Fri, 07 Jun 2013 11:45:06 +0530 [thread overview]
Message-ID: <51B17A6A.7060709@linux.vnet.ibm.com> (raw)
In-Reply-To: <51AC35F0.4010400@linux.vnet.ibm.com>
On 06/03/2013 11:51 AM, Raghavendra K T wrote:
> On 06/03/2013 07:10 AM, Raghavendra K T wrote:
>> On 06/02/2013 09:50 PM, Jiannan Ouyang wrote:
>>> On Sun, Jun 2, 2013 at 1:07 AM, Gleb Natapov <gleb@redhat.com> wrote:
>>>
>>>> High level question here. We have a big hope for "Preemptable Ticket
>>>> Spinlock" patch series by Jiannan Ouyang to solve most, if not all,
>>>> ticketing spinlocks in overcommit scenarios problem without need for
>>>> PV.
>>>> So how this patch series compares with his patches on PLE enabled
>>>> processors?
>>>>
>>>
>>> No experiment results yet.
>>>
>>> An error is reported on a 20 core VM. I'm during an internship
>>> relocation, and will start work on it next week.
>>
>> Preemptable spinlocks' testing update:
>> I hit the same softlockup problem while testing on 32 core machine with
>> 32 guest vcpus that Andrew had reported.
>>
>> After that i started tuning TIMEOUT_UNIT, and when I went till (1<<8),
>> things seemed to be manageable for undercommit cases.
>> But I still see degradation for undercommit w.r.t baseline itself on 32
>> core machine (after tuning).
>>
>> (37.5% degradation w.r.t base line).
>> I can give the full report after the all tests complete.
>>
>> For over-commit cases, I again started hitting softlockups (and
>> degradation is worse). But as I said in the preemptable thread, the
>> concept of preemptable locks looks promising (though I am still not a
>> fan of embedded TIMEOUT mechanism)
>>
>> Here is my opinion of TODOs for preemptable locks to make it better ( I
>> think I need to paste in the preemptable thread also)
>>
>> 1. Current TIMEOUT UNIT seem to be on higher side and also it does not
>> scale well with large guests and also overcommit. we need to have a
>> sort of adaptive mechanism and better is sort of different TIMEOUT_UNITS
>> for different types of lock too. The hashing mechanism that was used in
>> Rik's spinlock backoff series fits better probably.
>>
>> 2. I do not think TIMEOUT_UNIT itself would work great when we have a
>> big queue (for large guests / overcommits) for lock.
>> one way is to add a PV hook that does yield hypercall immediately for
>> the waiters above some THRESHOLD so that they don't burn the CPU.
>> ( I can do POC to check if that idea works in improving situation
>> at some later point of time)
>>
>
> Preemptable-lock results from my run with 2^8 TIMEOUT:
>
> +-----------+-----------+-----------+------------+-----------+
> ebizzy (records/sec) higher is better
> +-----------+-----------+-----------+------------+-----------+
> base stdev patched stdev %improvement
> +-----------+-----------+-----------+------------+-----------+
> 1x 5574.9000 237.4997 3484.2000 113.4449 -37.50202
> 2x 2741.5000 561.3090 351.5000 140.5420 -87.17855
> 3x 2146.2500 216.7718 194.8333 85.0303 -90.92215
> 4x 1663.0000 141.9235 101.0000 57.7853 -93.92664
> +-----------+-----------+-----------+------------+-----------+
> +-----------+-----------+-----------+------------+-----------+
> dbench (Throughput) higher is better
> +-----------+-----------+-----------+------------+-----------+
> base stdev patched stdev %improvement
> +-----------+-----------+-----------+------------+-----------+
> 1x 14111.5600 754.4525 3930.1602 2547.2369 -72.14936
> 2x 2481.6270 71.2665 181.1816 89.5368 -92.69908
> 3x 1510.2483 31.8634 104.7243 53.2470 -93.06576
> 4x 1029.4875 16.9166 72.3738 38.2432 -92.96992
> +-----------+-----------+-----------+------------+-----------+
>
> Note we can not trust on overcommit results because of softlock-ups
>
Hi, I tried
(1) TIMEOUT=(2^7)
(2) having yield hypercall that uses kvm_vcpu_on_spin() to do directed
yield to other vCPUs.
Now I do not see any soft-lockup in overcommit cases and results are
better now (except ebizzy 1x). and for dbench I see now it is closer to
base and even improvement in 4x
+-----------+-----------+-----------+------------+-----------+
ebizzy (records/sec) higher is better
+-----------+-----------+-----------+------------+-----------+
base stdev patched stdev %improvement
+-----------+-----------+-----------+------------+-----------+
5574.9000 237.4997 523.7000 1.4181 -90.60611
2741.5000 561.3090 597.8000 34.9755 -78.19442
2146.2500 216.7718 902.6667 82.4228 -57.94215
1663.0000 141.9235 1245.0000 67.2989 -25.13530
+-----------+-----------+-----------+------------+-----------+
+-----------+-----------+-----------+------------+-----------+
dbench (Throughput) higher is better
+-----------+-----------+-----------+------------+-----------+
base stdev patched stdev %improvement
+-----------+-----------+-----------+------------+-----------+
14111.5600 754.4525 884.9051 24.4723 -93.72922
2481.6270 71.2665 2383.5700 333.2435 -3.95132
1510.2483 31.8634 1477.7358 50.5126 -2.15279
1029.4875 16.9166 1075.9225 13.9911 4.51050
+-----------+-----------+-----------+------------+-----------+
IMO hash based timeout is worth a try further.
I think little more tuning will get more better results.
Jiannan, When you start working on this, I can also help
to get best of preemptable lock idea if you wish and share
the patches I tried.
WARNING: multiple messages have this Message-ID (diff)
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jiannan Ouyang <ouyang@cs.pitt.edu>, Gleb Natapov <gleb@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
gregkh@suse.de, KVM <kvm@vger.kernel.org>,
linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
Andrew Jones <drjones@redhat.com>,
virtualization@lists.linux-foundation.org, andi@firstfloor.org,
"H. Peter Anvin" <hpa@zytor.com>,
stefano.stabellini@eu.citrix.com, xen-devel@lists.xensource.com,
x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
"Andrew M. Theurer" <habanero@linux.vnet.ibm.com>,
Rik van Riel <riel@redhat.com>,
konrad.wilk@oracle.com, Avi Kivity <avi.kivity@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
chegu vinod <chegu_vinod@hp.com>,
LKML <linux-kernel@vger.kernel.org>,
Srivatsa Vaddagiri <srivatsa.vaddagiri@gmail.com>,
attilio.rao@citrix.com, pbonzini@redhat.com,
torvalds@linux-foundation.org, stephan.diestelhorst@amd.com
Subject: Re: [PATCH RFC V9 0/19] Paravirtualized ticket spinlocks
Date: Fri, 07 Jun 2013 11:45:06 +0530 [thread overview]
Message-ID: <51B17A6A.7060709@linux.vnet.ibm.com> (raw)
In-Reply-To: <51AC35F0.4010400@linux.vnet.ibm.com>
On 06/03/2013 11:51 AM, Raghavendra K T wrote:
> On 06/03/2013 07:10 AM, Raghavendra K T wrote:
>> On 06/02/2013 09:50 PM, Jiannan Ouyang wrote:
>>> On Sun, Jun 2, 2013 at 1:07 AM, Gleb Natapov <gleb@redhat.com> wrote:
>>>
>>>> High level question here. We have a big hope for "Preemptable Ticket
>>>> Spinlock" patch series by Jiannan Ouyang to solve most, if not all,
>>>> ticketing spinlocks in overcommit scenarios problem without need for
>>>> PV.
>>>> So how this patch series compares with his patches on PLE enabled
>>>> processors?
>>>>
>>>
>>> No experiment results yet.
>>>
>>> An error is reported on a 20 core VM. I'm during an internship
>>> relocation, and will start work on it next week.
>>
>> Preemptable spinlocks' testing update:
>> I hit the same softlockup problem while testing on 32 core machine with
>> 32 guest vcpus that Andrew had reported.
>>
>> After that i started tuning TIMEOUT_UNIT, and when I went till (1<<8),
>> things seemed to be manageable for undercommit cases.
>> But I still see degradation for undercommit w.r.t baseline itself on 32
>> core machine (after tuning).
>>
>> (37.5% degradation w.r.t base line).
>> I can give the full report after the all tests complete.
>>
>> For over-commit cases, I again started hitting softlockups (and
>> degradation is worse). But as I said in the preemptable thread, the
>> concept of preemptable locks looks promising (though I am still not a
>> fan of embedded TIMEOUT mechanism)
>>
>> Here is my opinion of TODOs for preemptable locks to make it better ( I
>> think I need to paste in the preemptable thread also)
>>
>> 1. Current TIMEOUT UNIT seem to be on higher side and also it does not
>> scale well with large guests and also overcommit. we need to have a
>> sort of adaptive mechanism and better is sort of different TIMEOUT_UNITS
>> for different types of lock too. The hashing mechanism that was used in
>> Rik's spinlock backoff series fits better probably.
>>
>> 2. I do not think TIMEOUT_UNIT itself would work great when we have a
>> big queue (for large guests / overcommits) for lock.
>> one way is to add a PV hook that does yield hypercall immediately for
>> the waiters above some THRESHOLD so that they don't burn the CPU.
>> ( I can do POC to check if that idea works in improving situation
>> at some later point of time)
>>
>
> Preemptable-lock results from my run with 2^8 TIMEOUT:
>
> +-----------+-----------+-----------+------------+-----------+
> ebizzy (records/sec) higher is better
> +-----------+-----------+-----------+------------+-----------+
> base stdev patched stdev %improvement
> +-----------+-----------+-----------+------------+-----------+
> 1x 5574.9000 237.4997 3484.2000 113.4449 -37.50202
> 2x 2741.5000 561.3090 351.5000 140.5420 -87.17855
> 3x 2146.2500 216.7718 194.8333 85.0303 -90.92215
> 4x 1663.0000 141.9235 101.0000 57.7853 -93.92664
> +-----------+-----------+-----------+------------+-----------+
> +-----------+-----------+-----------+------------+-----------+
> dbench (Throughput) higher is better
> +-----------+-----------+-----------+------------+-----------+
> base stdev patched stdev %improvement
> +-----------+-----------+-----------+------------+-----------+
> 1x 14111.5600 754.4525 3930.1602 2547.2369 -72.14936
> 2x 2481.6270 71.2665 181.1816 89.5368 -92.69908
> 3x 1510.2483 31.8634 104.7243 53.2470 -93.06576
> 4x 1029.4875 16.9166 72.3738 38.2432 -92.96992
> +-----------+-----------+-----------+------------+-----------+
>
> Note we can not trust on overcommit results because of softlock-ups
>
Hi, I tried
(1) TIMEOUT=(2^7)
(2) having yield hypercall that uses kvm_vcpu_on_spin() to do directed
yield to other vCPUs.
Now I do not see any soft-lockup in overcommit cases and results are
better now (except ebizzy 1x). and for dbench I see now it is closer to
base and even improvement in 4x
+-----------+-----------+-----------+------------+-----------+
ebizzy (records/sec) higher is better
+-----------+-----------+-----------+------------+-----------+
base stdev patched stdev %improvement
+-----------+-----------+-----------+------------+-----------+
5574.9000 237.4997 523.7000 1.4181 -90.60611
2741.5000 561.3090 597.8000 34.9755 -78.19442
2146.2500 216.7718 902.6667 82.4228 -57.94215
1663.0000 141.9235 1245.0000 67.2989 -25.13530
+-----------+-----------+-----------+------------+-----------+
+-----------+-----------+-----------+------------+-----------+
dbench (Throughput) higher is better
+-----------+-----------+-----------+------------+-----------+
base stdev patched stdev %improvement
+-----------+-----------+-----------+------------+-----------+
14111.5600 754.4525 884.9051 24.4723 -93.72922
2481.6270 71.2665 2383.5700 333.2435 -3.95132
1510.2483 31.8634 1477.7358 50.5126 -2.15279
1029.4875 16.9166 1075.9225 13.9911 4.51050
+-----------+-----------+-----------+------------+-----------+
IMO hash based timeout is worth a try further.
I think little more tuning will get more better results.
Jiannan, When you start working on this, I can also help
to get best of preemptable lock idea if you wish and share
the patches I tried.
next prev parent reply other threads:[~2013-06-07 6:11 UTC|newest]
Thread overview: 192+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-01 19:21 [PATCH RFC V9 0/19] Paravirtualized ticket spinlocks Raghavendra K T
2013-06-01 19:21 ` Raghavendra K T
2013-06-01 19:21 ` [PATCH RFC V9 1/19] x86/spinlock: Replace pv spinlocks with pv ticketlocks Raghavendra K T
2013-06-01 19:21 ` Raghavendra K T
2013-06-01 19:21 ` Raghavendra K T
2013-06-01 20:32 ` Jeremy Fitzhardinge
2013-06-01 20:32 ` Jeremy Fitzhardinge
2013-06-02 6:54 ` Raghavendra K T
2013-06-02 6:54 ` Raghavendra K T
2013-06-01 20:32 ` Jeremy Fitzhardinge
2013-06-01 19:22 ` [PATCH RFC V9 2/19] x86/ticketlock: Don't inline _spin_unlock when using paravirt spinlocks Raghavendra K T
2013-06-01 19:22 ` Raghavendra K T
2013-06-01 19:22 ` Raghavendra K T
2013-06-03 15:28 ` Konrad Rzeszutek Wilk
2013-06-03 15:28 ` Konrad Rzeszutek Wilk
2013-06-01 19:22 ` [PATCH RFC V9 3/19] x86/ticketlock: Collapse a layer of functions Raghavendra K T
2013-06-01 19:22 ` Raghavendra K T
2013-06-01 19:22 ` Raghavendra K T
2013-06-03 15:28 ` Konrad Rzeszutek Wilk
2013-06-03 15:28 ` Konrad Rzeszutek Wilk
2013-06-01 19:22 ` [PATCH RFC V9 4/19] xen: Defer spinlock setup until boot CPU setup Raghavendra K T
2013-06-01 19:22 ` Raghavendra K T
2013-06-01 19:22 ` Raghavendra K T
2013-06-01 19:23 ` [PATCH RFC V9 5/19] xen/pvticketlock: Xen implementation for PV ticket locks Raghavendra K T
2013-06-01 19:23 ` Raghavendra K T
2013-06-03 16:03 ` Konrad Rzeszutek Wilk
2013-06-03 16:03 ` Konrad Rzeszutek Wilk
2013-06-04 7:21 ` Raghavendra K T
2013-06-04 7:21 ` Raghavendra K T
2013-06-01 19:23 ` Raghavendra K T
2013-06-01 19:23 ` [PATCH RFC V9 6/19] xen/pvticketlocks: Add xen_nopvspin parameter to disable xen pv ticketlocks Raghavendra K T
2013-06-01 19:23 ` Raghavendra K T
2013-06-01 19:23 ` Raghavendra K T
2013-06-01 19:23 ` [PATCH RFC V9 7/19] x86/pvticketlock: Use callee-save for lock_spinning Raghavendra K T
2013-06-01 19:23 ` Raghavendra K T
2013-06-01 19:23 ` Raghavendra K T
2013-06-01 19:24 ` [PATCH RFC V9 8/19] x86/pvticketlock: When paravirtualizing ticket locks, increment by 2 Raghavendra K T
2013-06-01 19:24 ` Raghavendra K T
2013-06-01 19:24 ` Raghavendra K T
2013-06-03 15:53 ` Konrad Rzeszutek Wilk
2013-06-03 15:53 ` Konrad Rzeszutek Wilk
2013-06-01 19:24 ` [PATCH RFC V9 9/19] Split out rate limiting from jump_label.h Raghavendra K T
2013-06-01 19:24 ` Raghavendra K T
2013-06-01 19:24 ` Raghavendra K T
2013-06-03 15:56 ` Konrad Rzeszutek Wilk
2013-06-03 15:56 ` Konrad Rzeszutek Wilk
2013-06-04 7:15 ` Raghavendra K T
2013-06-04 7:15 ` Raghavendra K T
2013-06-01 19:24 ` [PATCH RFC V9 10/19] x86/ticketlock: Add slowpath logic Raghavendra K T
2013-06-01 19:24 ` Raghavendra K T
2013-06-01 19:24 ` Raghavendra K T
2013-06-01 19:24 ` [PATCH RFC V9 11/19] xen/pvticketlock: Allow interrupts to be enabled while blocking Raghavendra K T
2013-06-01 19:24 ` Raghavendra K T
2013-06-01 19:24 ` Raghavendra K T
2013-06-01 19:25 ` [PATCH RFC V9 12/19] xen: Enable PV ticketlocks on HVM Xen Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-03 15:57 ` Konrad Rzeszutek Wilk
2013-06-03 15:57 ` Konrad Rzeszutek Wilk
2013-06-04 7:16 ` Raghavendra K T
2013-06-04 7:16 ` Raghavendra K T
2013-06-04 14:44 ` Konrad Rzeszutek Wilk
2013-06-04 14:44 ` Konrad Rzeszutek Wilk
2013-06-04 15:00 ` Raghavendra K T
2013-06-04 15:00 ` Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-01 19:25 ` [PATCH RFC V9 13/19] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-01 19:25 ` [PATCH RFC V9 14/19] kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-01 19:25 ` [PATCH RFC V9 15/19] kvm guest : Add configuration support to enable debug information for KVM Guests Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-01 19:25 ` [PATCH RFC V9 16/19] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-03 16:00 ` Konrad Rzeszutek Wilk
2013-06-03 16:00 ` Konrad Rzeszutek Wilk
2013-06-04 7:19 ` Raghavendra K T
2013-06-04 7:19 ` Raghavendra K T
2013-06-01 19:25 ` Raghavendra K T
2013-06-01 19:26 ` [PATCH RFC V9 17/19] kvm hypervisor : Simplify kvm_for_each_vcpu with kvm_irq_delivery_to_apic Raghavendra K T
2013-06-01 19:26 ` Raghavendra K T
2013-06-01 19:26 ` Raghavendra K T
2013-06-01 19:26 ` [PATCH RFC V9 18/19] Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock Raghavendra K T
2013-06-01 19:26 ` Raghavendra K T
2013-06-01 19:26 ` Raghavendra K T
2013-06-03 16:04 ` Konrad Rzeszutek Wilk
2013-06-03 16:04 ` Konrad Rzeszutek Wilk
2013-06-04 7:22 ` Raghavendra K T
2013-06-04 7:22 ` Raghavendra K T
2013-06-01 19:26 ` [PATCH RFC V9 19/19] kvm hypervisor: Add directed yield in vcpu block path Raghavendra K T
2013-06-01 19:26 ` Raghavendra K T
2013-06-01 19:26 ` Raghavendra K T
2013-06-03 16:05 ` Konrad Rzeszutek Wilk
2013-06-03 16:05 ` Konrad Rzeszutek Wilk
2013-06-04 7:28 ` Raghavendra K T
2013-06-04 7:28 ` Raghavendra K T
2013-06-02 8:07 ` [PATCH RFC V9 0/19] Paravirtualized ticket spinlocks Gleb Natapov
2013-06-02 8:07 ` Gleb Natapov
2013-06-02 16:20 ` Jiannan Ouyang
2013-06-02 16:20 ` Jiannan Ouyang
2013-06-03 1:40 ` Raghavendra K T
2013-06-03 1:40 ` Raghavendra K T
2013-06-03 6:21 ` Raghavendra K T
2013-06-07 6:15 ` Raghavendra K T [this message]
2013-06-07 6:15 ` Raghavendra K T
2013-06-07 13:29 ` Andrew Theurer
2013-06-07 13:29 ` Andrew Theurer
2013-06-07 23:41 ` Jiannan Ouyang
2013-06-07 23:41 ` Jiannan Ouyang
2013-06-07 23:41 ` Jiannan Ouyang
2013-06-03 6:21 ` Raghavendra K T
2013-06-02 16:20 ` Jiannan Ouyang
2013-06-25 14:50 ` Andrew Theurer
2013-06-25 14:50 ` Andrew Theurer
2013-06-26 8:45 ` Raghavendra K T
2013-06-26 8:45 ` Raghavendra K T
2013-06-26 11:37 ` Andrew Jones
2013-06-26 11:37 ` Andrew Jones
2013-06-26 12:52 ` Gleb Natapov
2013-06-26 12:52 ` Gleb Natapov
2013-06-26 13:40 ` Raghavendra K T
2013-06-26 13:40 ` Raghavendra K T
2013-06-26 14:39 ` Chegu Vinod
2013-06-26 15:37 ` Raghavendra K T
2013-06-26 15:37 ` Raghavendra K T
2013-06-26 16:11 ` Gleb Natapov
2013-06-26 16:11 ` Gleb Natapov
2013-06-26 17:54 ` Raghavendra K T
2013-07-09 9:11 ` Raghavendra K T
2013-07-09 9:11 ` Raghavendra K T
2013-07-10 10:33 ` Gleb Natapov
2013-07-10 10:33 ` Gleb Natapov
2013-07-10 10:40 ` Peter Zijlstra
2013-07-10 10:40 ` Peter Zijlstra
2013-07-10 10:47 ` Gleb Natapov
2013-07-10 10:47 ` Gleb Natapov
2013-07-10 11:28 ` Raghavendra K T
2013-07-10 11:28 ` Raghavendra K T
2013-07-10 11:29 ` Gleb Natapov
2013-07-10 11:29 ` Gleb Natapov
2013-07-10 11:40 ` Raghavendra K T
2013-07-10 11:40 ` Raghavendra K T
2013-07-10 15:03 ` Konrad Rzeszutek Wilk
2013-07-10 15:03 ` Konrad Rzeszutek Wilk
2013-07-10 15:16 ` Gleb Natapov
2013-07-10 15:16 ` Gleb Natapov
2013-07-11 0:12 ` Konrad Rzeszutek Wilk
2013-07-11 0:12 ` Konrad Rzeszutek Wilk
2013-07-10 11:24 ` Raghavendra K T
2013-07-10 11:24 ` Raghavendra K T
2013-07-10 11:41 ` Gleb Natapov
2013-07-10 11:41 ` Gleb Natapov
2013-07-10 11:50 ` Raghavendra K T
2013-07-10 11:50 ` Raghavendra K T
2013-07-11 9:13 ` Raghavendra K T
2013-07-11 9:13 ` Raghavendra K T
2013-07-11 9:48 ` Gleb Natapov
2013-07-11 9:48 ` Gleb Natapov
2013-07-11 10:10 ` Raghavendra K T
2013-07-11 10:11 ` Gleb Natapov
2013-07-11 10:11 ` Gleb Natapov
2013-07-11 10:53 ` Raghavendra K T
2013-07-11 10:53 ` Raghavendra K T
2013-07-11 10:56 ` Gleb Natapov
2013-07-11 10:56 ` Gleb Natapov
2013-07-11 11:14 ` Raghavendra K T
2013-07-11 11:14 ` Raghavendra K T
2013-07-11 10:10 ` Raghavendra K T
2013-06-26 17:54 ` Raghavendra K T
2013-06-26 14:13 ` Konrad Rzeszutek Wilk
2013-06-26 14:13 ` Konrad Rzeszutek Wilk
2013-06-26 15:56 ` Andrew Theurer
2013-06-26 15:56 ` Andrew Theurer
2013-07-01 9:30 ` Raghavendra K T
2013-07-01 9:30 ` Raghavendra K T
-- strict thread matches above, loose matches on Subject: below --
2013-06-01 19:21 Raghavendra K T
2013-06-01 8:21 Raghavendra K T
2013-06-01 8:21 Raghavendra K T
2013-06-01 8:21 ` Raghavendra K T
2013-06-01 19:21 ` Raghavendra KT
2013-06-01 19:21 ` Raghavendra KT
2013-06-01 20:14 ` Andi Kleen
2013-06-01 20:28 ` Jeremy Fitzhardinge
2013-06-01 20:28 ` Jeremy Fitzhardinge
2013-06-01 20:46 ` Andi Kleen
2013-06-01 20:46 ` Andi Kleen
2013-06-01 20:28 ` Jeremy Fitzhardinge
2013-06-04 10:58 ` Raghavendra K T
2013-06-04 10:58 ` Raghavendra K T
2013-06-01 20:14 ` Andi Kleen
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=51B17A6A.7060709@linux.vnet.ibm.com \
--to=raghavendra.kt@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=andi@firstfloor.org \
--cc=attilio.rao@citrix.com \
--cc=avi.kivity@gmail.com \
--cc=chegu_vinod@hp.com \
--cc=drjones@redhat.com \
--cc=gleb@redhat.com \
--cc=gregkh@suse.de \
--cc=habanero@linux.vnet.ibm.com \
--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@redhat.com \
--cc=mtosatti@redhat.com \
--cc=ouyang@cs.pitt.edu \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=srivatsa.vaddagiri@gmail.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=stephan.diestelhorst@amd.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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.