On Sat, Mar 31, 2012 at 09:37:45AM +0530, Srivatsa Vaddagiri wrote:
* Thomas Gleixner t...@linutronix.de [2012-03-31 00:07:58]:
I know that Peter is going to go berserk on me, but if we are running
a paravirt guest then it's simple to provide a mechanism which allows
the host (aka
On Mon, 2012-04-16 at 16:44 +0100, Konrad Rzeszutek Wilk wrote:
On Sat, Mar 31, 2012 at 09:37:45AM +0530, Srivatsa Vaddagiri wrote:
* Thomas Gleixner t...@linutronix.de [2012-03-31 00:07:58]:
I know that Peter is going to go berserk on me, but if we are running
a paravirt guest then
On 04/16/2012 09:36 AM, Ian Campbell wrote:
On Mon, 2012-04-16 at 16:44 +0100, Konrad Rzeszutek Wilk wrote:
On Sat, Mar 31, 2012 at 09:37:45AM +0530, Srivatsa Vaddagiri wrote:
* Thomas Gleixner t...@linutronix.de [2012-03-31 00:07:58]:
I know that Peter is going to go berserk on me, but if we
* Ian Campbell ian.campb...@citrix.com [2012-04-16 17:36:35]:
The current pv-spinlock patches however does not track which vcpu is
spinning at what head of the ticketlock. I suppose we can consider
that optimization in future and see how much benefit it provides (over
plain
On Sat, Mar 31, 2012 at 12:07:58AM +0200, Thomas Gleixner wrote:
On Fri, 30 Mar 2012, H. Peter Anvin wrote:
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
The real question is whether these heuristics
On 04/01/2012 07:23 PM, Avi Kivity wrote:
On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d3b98b1..5127668 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1608,15
On 04/02/2012 12:51 PM, Raghavendra K T wrote:
On 04/01/2012 07:23 PM, Avi Kivity wrote:
On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d3b98b1..5127668 100644
---
On 04/02/2012 12:26 PM, Thomas Gleixner wrote:
One thing about it is that it can give many false positives. Consider a
fine-grained spinlock that is being accessed by many threads. That is,
the lock is taken and released with high frequency, but there is no
contention, because each vcpu
On 04/05/2012 02:31 PM, Avi Kivity wrote:
On 04/02/2012 12:51 PM, Raghavendra K T wrote:
On 04/01/2012 07:23 PM, Avi Kivity wrote:
On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index
On Sun, 1 Apr 2012, Avi Kivity wrote:
On 03/31/2012 01:07 AM, Thomas Gleixner wrote:
On Fri, 30 Mar 2012, H. Peter Anvin wrote:
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
The real question is
On Fri, 2012-03-30 at 23:07 +0100, Thomas Gleixner wrote:
So if we need to fiddle with the scheduler and frankly that's the only
way to get a real gain (the numbers, which are achieved by this
patches, are not that impressive) then the question arises whether we
should turn the whole thing
On 04/01/2012 07:23 PM, Avi Kivity wrote:
On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d3b98b1..5127668 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1608,15
On 04/02/2012 03:21 PM, Raghavendra K T wrote:
On 04/01/2012 07:23 PM, Avi Kivity wrote:
On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 5127668..3fa912a 100644
---
On 03/30/2012 01:07 PM, Raghavendra K T wrote:
On 03/29/2012 11:33 PM, Raghavendra K T wrote:
On 03/29/2012 03:28 PM, Avi Kivity wrote:
On 03/28/2012 08:21 PM, Raghavendra K T wrote:
I really like below ideas. Thanks for that!.
- from the PLE handler, don't wake up a vcpu that is sleeping
On 03/31/2012 01:07 AM, Thomas Gleixner wrote:
On Fri, 30 Mar 2012, H. Peter Anvin wrote:
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
The real question is whether these heuristics are the correct
On 04/01/2012 06:48 PM, Avi Kivity wrote:
On 03/30/2012 01:07 PM, Raghavendra K T wrote:
On 03/29/2012 11:33 PM, Raghavendra K T wrote:
On 03/29/2012 03:28 PM, Avi Kivity wrote:
On 03/28/2012 08:21 PM, Raghavendra K T wrote:
I really like below ideas. Thanks for that!.
- from the PLE
On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d3b98b1..5127668 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1608,15 +1608,18 @@ void kvm_vcpu_on_spin(struct
On 04/01/2012 07:23 PM, Avi Kivity wrote:
On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
I'm interested in how PLE does vs. your patches, both with PLE enabled
and disabled.
Sure. will update with the experimental results.
--
To
On 03/31/2012 12:07 AM, Thomas Gleixner wrote:
On Fri, 30 Mar 2012, H. Peter Anvin wrote:
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
The real question is whether these heuristics are the correct approach
* Andi Kleen a...@firstfloor.org wrote:
Care to back that up with numbers and proper trace evidence
instead of handwaving?
E.g. my plumbers presentations on lock and mm scalability from
last year has some graphs that show this very clearly, plus
some additional data on the mutexes.
On 03/29/2012 11:33 PM, Raghavendra K T wrote:
On 03/29/2012 03:28 PM, Avi Kivity wrote:
On 03/28/2012 08:21 PM, Raghavendra K T wrote:
I really like below ideas. Thanks for that!.
- from the PLE handler, don't wake up a vcpu that is sleeping because it
is waiting for a kick
How about,
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the
On Fri, 30 Mar 2012, H. Peter Anvin wrote:
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
The real question is whether these heuristics are the correct approach
or not.
If I look at it from the non
So if a guest exits due to an external event it's easy to inspect the
state of that guest and avoid to schedule away when it was interrupted
in a spinlock held section. That guest/host shared state needs to be
On a large system under high contention sleeping can perform surprisingly
well.
On 03/31/2012 01:56 AM, H. Peter Anvin wrote:
What is the current status of this patchset? I haven't looked at it too
closely because I have been focused on 3.4 up until now...
Thanks Peter,
Currently targeting the patchset for next merge window. IMO These
patches are in good shape now. I'
* Thomas Gleixner t...@linutronix.de [2012-03-31 00:07:58]:
I know that Peter is going to go berserk on me, but if we are running
a paravirt guest then it's simple to provide a mechanism which allows
the host (aka hypervisor) to check that in the guest just by looking
at some global state.
* Srivatsa Vaddagiri va...@linux.vnet.ibm.com [2012-03-31 09:37:45]:
The issue is with ticketlocks though. VCPUs could go into a spin w/o
a lock being held by anybody. Say VCPUs 1-99 try to grab a lock in
that order (on a host with one cpu). VCPU1 wins (after VCPU0 releases it)
and releases
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
On 03/29/2012 03:28 PM, Avi Kivity wrote:
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
I am happy to see this issue receiving some attention and second the
wish to see these patches be considered for further review and
inclusion in an upcoming release.
Overcommit is not as common in enterprise and single-tenant
virtualized environments as it is in multi-tenant environments, and
On 03/28/2012 09:39 PM, Alan Meadows wrote:
I am happy to see this issue receiving some attention and second the
wish to see these patches be considered for further review and inclusion
in an upcoming release.
Overcommit is not as common in enterprise and single-tenant virtualized
environments
On 03/26/2012 07:55 PM, Avi Kivity wrote:
On 03/21/2012 12:20 PM, Raghavendra K T wrote:
From: Jeremy Fitzhardingejeremy.fitzhardi...@citrix.com
[...]
This series provides a Xen implementation, but it should be
straightforward to add a KVM implementation as well.
Looks like a good
On 03/21/2012 12:20 PM, Raghavendra K T wrote:
From: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
Changes since last posting: (Raghavendra K T)
[
- Rebased to linux-3.3-rc6.
- used function+enum in place of macro (better type checking)
- use cmpxchg while resetting zero status for
From: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
Changes since last posting: (Raghavendra K T)
[
- Rebased to linux-3.3-rc6.
- used function+enum in place of macro (better type checking)
- use cmpxchg while resetting zero status for possible race
[suggested by Dave Hansen for
34 matches
Mail list logo
