On 10/29/2012 11:24 PM, Peter Zijlstra wrote:
On Mon, 2012-10-29 at 19:37 +0530, Raghavendra K T wrote:
+/*
+ * A load of 2048 corresponds to 1:1 overcommit
+ * undercommit threshold is half the 1:1 overcommit
+ * overcommit threshold is 1.75 times of 1:1 overcommit threshold
+ */
+#define
On 10/30/2012 12:04 PM, Andrew Jones wrote:
On Tue, Oct 30, 2012 at 11:27:52AM +0530, Raghavendra K T wrote:
On 10/29/2012 11:24 PM, Peter Zijlstra wrote:
On Mon, 2012-10-29 at 19:37 +0530, Raghavendra K T wrote:
+/*
+ * A load of 2048 corresponds to 1:1 overcommit
+ * undercommit threshold
On 10/30/2012 01:44 PM, Peter Zijlstra wrote:
On Tue, 2012-10-30 at 11:27 +0530, Raghavendra K T wrote:
Okay, now IIUC, usage of *any* global measure is bad?
Yep, people like to carve up their machines, esp. now that they're
somewhat bigger than they used to be. This can result in very
On 10/30/2012 05:47 PM, Andrew Theurer wrote:
On Mon, 2012-10-29 at 19:36 +0530, Raghavendra K T wrote:
In some special scenarios like #vcpu = #pcpu, PLE handler may
prove very costly, because there is no need to iterate over vcpus
and do unsuccessful yield_to burning CPU.
Similarly, when we
On 10/30/2012 02:37 PM, Andrew Jones wrote:
On Tue, Oct 30, 2012 at 01:01:54PM +0530, Raghavendra K T wrote:
On 10/30/2012 12:04 PM, Andrew Jones wrote:
On Tue, Oct 30, 2012 at 11:27:52AM +0530, Raghavendra K T wrote:
On 10/29/2012 11:24 PM, Peter Zijlstra wrote:
On Mon, 2012-10-29 at 19:37
On 10/31/2012 06:08 PM, Avi Kivity wrote:
On 10/29/2012 04:07 PM, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Also we do not update last boosted vcpu in failure cases.
#endif
+
void kvm_vcpu_on_spin(struct kvm_vcpu *me)
{
struct kvm *kvm = me
On 10/31/2012 06:11 PM, Raghavendra K T wrote:
On 10/31/2012 06:08 PM, Avi Kivity wrote:
On 10/29/2012 04:07 PM, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Also we do not update last boosted vcpu in failure cases.
#endif
+
void kvm_vcpu_on_spin(struct
On 10/31/2012 07:11 PM, Avi Kivity wrote:
On 10/31/2012 03:15 PM, Raghavendra K T wrote:
On 10/31/2012 06:11 PM, Raghavendra K T wrote:
On 10/31/2012 06:08 PM, Avi Kivity wrote:
On 10/29/2012 04:07 PM, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Also we do
On 09/24/2012 05:03 PM, Peter Zijlstra wrote:
On Fri, 2012-09-21 at 17:30 +0530, Raghavendra K T wrote:
+unsigned long rq_nr_running(void)
+{
+ return this_rq()-nr_running;
+}
+EXPORT_SYMBOL(rq_nr_running);
Uhm,.. no, that's a horrible thing to export.
True.. I had the same fear
On 09/24/2012 05:04 PM, Peter Zijlstra wrote:
On Fri, 2012-09-21 at 17:29 +0530, Raghavendra K T wrote:
In some special scenarios like #vcpu= #pcpu, PLE handler may
prove very costly, because there is no need to iterate over vcpus
and do unsuccessful yield_to burning CPU.
What's the costly
On 09/24/2012 02:12 PM, Dor Laor wrote:
In order to help PLE and pvticketlock converge I thought that a small
test code should be developed to test this in a predictable,
deterministic way.
The idea is to have a guest kernel module that spawn a new thread each
time you write to a /sys/
On 09/24/2012 06:06 PM, Peter Zijlstra wrote:
On Mon, 2012-09-24 at 17:22 +0530, Raghavendra K T wrote:
On 09/24/2012 05:04 PM, Peter Zijlstra wrote:
On Fri, 2012-09-21 at 17:29 +0530, Raghavendra K T wrote:
In some special scenarios like #vcpu= #pcpu, PLE handler may
prove very costly
On 09/24/2012 07:24 PM, Peter Zijlstra wrote:
On Mon, 2012-09-24 at 18:59 +0530, Raghavendra K T wrote:
However Rik had a genuine concern in the cases where runqueue is not
equally distributed and lockholder might actually be on a different run
queue but not running.
Load should eventually
On 09/25/2012 03:56 AM, David Rientjes wrote:
On Fri, 21 Sep 2012, Raghavendra K T wrote:
I think you meant we can read data only once. second time onwards we don't see
any data. (except when fd is forked by child/ races in
threads).
You can read(2) as many times as you want after it's
On 09/24/2012 09:11 PM, Avi Kivity wrote:
On 09/21/2012 08:24 PM, Raghavendra K T wrote:
On 09/21/2012 06:32 PM, Rik van Riel wrote:
On 09/21/2012 08:00 AM, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
When total number of VCPUs of system is less than
On 09/24/2012 09:36 PM, Avi Kivity wrote:
On 09/24/2012 05:41 PM, Avi Kivity wrote:
case 2)
rq1 : vcpu1-wait(lockA) (spinning)
rq2 : vcpu3 (running) , vcpu2-holding(lockA) [scheduled out]
I agree that checking rq1 length is not proper in this case, and as you
rightly pointed out, we are in
On 09/24/2012 07:46 PM, Raghavendra K T wrote:
On 09/24/2012 07:24 PM, Peter Zijlstra wrote:
On Mon, 2012-09-24 at 18:59 +0530, Raghavendra K T wrote:
However Rik had a genuine concern in the cases where runqueue is not
equally distributed and lockholder might actually be on a different run
On 09/25/2012 02:24 PM, Avi Kivity wrote:
On 09/25/2012 10:09 AM, Raghavendra K T wrote:
On 09/24/2012 09:36 PM, Avi Kivity wrote:
On 09/24/2012 05:41 PM, Avi Kivity wrote:
case 2)
rq1 : vcpu1-wait(lockA) (spinning)
rq2 : vcpu3 (running) , vcpu2-holding(lockA) [scheduled out]
I agree
On 09/25/2012 08:30 PM, Dor Laor wrote:
On 09/24/2012 02:02 PM, Raghavendra K T wrote:
On 09/24/2012 02:12 PM, Dor Laor wrote:
In order to help PLE and pvticketlock converge I thought that a small
test code should be developed to test this in a predictable,
deterministic way.
The idea
On 09/26/2012 05:57 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Sep 25, 2012 at 05:00:30PM +0200, Dor Laor wrote:
On 09/24/2012 02:02 PM, Raghavendra K T wrote:
On 09/24/2012 02:12 PM, Dor Laor wrote:
In order to help PLE and pvticketlock converge I thought that a small
test code should
On 09/26/2012 06:27 PM, Andrew Jones wrote:
On Mon, Sep 24, 2012 at 02:36:05PM +0200, Peter Zijlstra wrote:
On Mon, 2012-09-24 at 17:22 +0530, Raghavendra K T wrote:
On 09/24/2012 05:04 PM, Peter Zijlstra wrote:
On Fri, 2012-09-21 at 17:29 +0530, Raghavendra K T wrote:
In some special
On 09/27/2012 02:06 PM, Avi Kivity wrote:
On 09/25/2012 03:40 PM, Raghavendra K T wrote:
On 09/24/2012 07:46 PM, Raghavendra K T wrote:
On 09/24/2012 07:24 PM, Peter Zijlstra wrote:
On Mon, 2012-09-24 at 18:59 +0530, Raghavendra K T wrote:
However Rik had a genuine concern in the cases where
On 09/27/2012 02:20 PM, Avi Kivity wrote:
On 09/25/2012 04:43 PM, Jiannan Ouyang wrote:
I've actually implemented this preempted_bitmap idea.
Interesting, please share the code if you can.
However, I'm doing this to expose this information to the guest, so the
guest is able to know if the
On 09/27/2012 03:58 PM, Andrew Jones wrote:
On Thu, Sep 27, 2012 at 03:19:45PM +0530, Raghavendra K T wrote:
On 09/25/2012 08:30 PM, Dor Laor wrote:
On 09/24/2012 02:02 PM, Raghavendra K T wrote:
On 09/24/2012 02:12 PM, Dor Laor wrote:
In order to help PLE and pvticketlock converge I thought
On 09/27/2012 05:33 PM, Avi Kivity wrote:
On 09/27/2012 01:23 PM, Raghavendra K T wrote:
This gives us a good case for tracking preemption on a per-vm basis. As
long as we aren't preempted, we can keep the PLE window high, and also
return immediately from the handler without looking
On 09/28/2012 11:15 AM, H. Peter Anvin wrote:
On 09/27/2012 10:38 PM, Raghavendra K T wrote:
+
+bool kvm_overcommitted()
+{
This better not be C...
I think you meant I should have had like kvm_overcommitted(void) and
(different function name perhaps)
or is it the body of function
On 09/28/2012 02:37 AM, Jiannan Ouyang wrote:
On Thu, Sep 27, 2012 at 4:50 AM, Avi Kivity a...@redhat.com
mailto:a...@redhat.com wrote:
On 09/25/2012 04:43 PM, Jiannan Ouyang wrote:
I've actually implemented this preempted_bitmap idea.
Interesting, please share the code if you
* Avi Kivity a...@redhat.com [2012-09-24 17:41:19]:
On 09/21/2012 08:24 PM, Raghavendra K T wrote:
On 09/21/2012 06:32 PM, Rik van Riel wrote:
On 09/21/2012 08:00 AM, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
When total number of VCPUs of system
* Avi Kivity a...@redhat.com [2012-09-30 13:13:09]:
On 09/30/2012 01:07 PM, Gleb Natapov wrote:
On Sun, Sep 30, 2012 at 10:18:17AM +0200, Avi Kivity wrote:
On 09/28/2012 08:16 AM, Raghavendra K T wrote:
+struct pv_sched_info {
+ unsigned long sched_bitmap
* Avi Kivity a...@redhat.com [2012-09-27 14:03:59]:
On 09/27/2012 01:23 PM, Raghavendra K T wrote:
[...]
2) looking at the result (comparing A C) , I do feel we have
significant in iterating over vcpus (when compared to even vmexit)
so We still would need undercommit fix sugested
On 10/03/2012 10:35 PM, Avi Kivity wrote:
On 10/03/2012 02:22 PM, Raghavendra K T wrote:
So I think it's worth trying again with ple_window of 2-4.
Hi Avi,
I ran different benchmarks increasing ple_window, and results does not
seem to be encouraging for increasing ple_window
On 10/03/2012 10:55 PM, Avi Kivity wrote:
On 10/03/2012 04:29 PM, Raghavendra K T wrote:
* Avi Kivity a...@redhat.com [2012-09-27 14:03:59]:
On 09/27/2012 01:23 PM, Raghavendra K T wrote:
[...]
2) looking at the result (comparing A C) , I do feel we have
significant in iterating over
On 10/04/2012 12:59 PM, Gleb Natapov wrote:
On Wed, Oct 03, 2012 at 04:56:57PM +0200, Avi Kivity wrote:
On 10/03/2012 04:17 PM, Raghavendra K T wrote:
* Avi Kivity a...@redhat.com [2012-09-30 13:13:09]:
On 09/30/2012 01:07 PM, Gleb Natapov wrote:
On Sun, Sep 30, 2012 at 10:18:17AM +0200
On 10/04/2012 06:11 PM, Avi Kivity wrote:
On 10/04/2012 12:49 PM, Raghavendra K T wrote:
On 10/03/2012 10:35 PM, Avi Kivity wrote:
On 10/03/2012 02:22 PM, Raghavendra K T wrote:
So I think it's worth trying again with ple_window of 2-4.
Hi Avi,
I ran different benchmarks
On 10/04/2012 06:14 PM, Avi Kivity wrote:
On 10/04/2012 12:56 PM, Raghavendra K T wrote:
On 10/03/2012 10:55 PM, Avi Kivity wrote:
On 10/03/2012 04:29 PM, Raghavendra K T wrote:
* Avi Kivity a...@redhat.com [2012-09-27 14:03:59]:
On 09/27/2012 01:23 PM, Raghavendra K T wrote:
[...]
2
On 10/04/2012 08:11 PM, Andrew Theurer wrote:
On Thu, 2012-10-04 at 14:41 +0200, Avi Kivity wrote:
On 10/04/2012 12:49 PM, Raghavendra K T wrote:
On 10/03/2012 10:35 PM, Avi Kivity wrote:
On 10/03/2012 02:22 PM, Raghavendra K T wrote:
So I think it's worth trying again with ple_window
* Raghavendra K T raghavendra...@linux.vnet.ibm.com [2012-10-31 22:36:25]:
On 10/31/2012 07:11 PM, Avi Kivity wrote:
On 10/31/2012 03:15 PM, Raghavendra K T wrote:
On 10/31/2012 06:11 PM, Raghavendra K T wrote:
On 10/31/2012 06:08 PM, Avi Kivity wrote:
On 10/29/2012 04:07 PM, Raghavendra K T
On 10/18/2012 06:09 PM, Avi Kivity wrote:
On 10/09/2012 08:51 PM, Raghavendra K T wrote:
Here is the summary:
We do get good benefit by increasing ple window. Though we don't
see good benefit for kernbench and sysbench, for ebizzy, we get huge
improvement for 1x scenario. (almost 2/3rd of ple
On 10/15/2012 08:04 PM, Andrew Theurer wrote:
On Mon, 2012-10-15 at 17:40 +0530, Raghavendra K T wrote:
On 10/11/2012 01:06 AM, Andrew Theurer wrote:
On Wed, 2012-10-10 at 23:24 +0530, Raghavendra K T wrote:
On 10/10/2012 08:29 AM, Andrew Theurer wrote:
On Wed, 2012-10-10 at 00:21 +0530
* Avi Kivity a...@redhat.com [2012-10-04 17:00:28]:
On 10/04/2012 03:07 PM, Peter Zijlstra wrote:
On Thu, 2012-10-04 at 14:41 +0200, Avi Kivity wrote:
Again the numbers are ridiculously high for arch_local_irq_restore.
Maybe there's a bad perf/kvm interaction when we're injecting an
On 10/10/2012 07:54 PM, Andrew Theurer wrote:
I ran 'perf sched map' on the dbench workload for medium and large VMs,
and I thought I would share some of the results. I think it helps to
visualize what's going on regarding the yielding.
These files are png bitmaps, generated from processing
On 10/10/2012 08:29 AM, Andrew Theurer wrote:
On Wed, 2012-10-10 at 00:21 +0530, Raghavendra K T wrote:
* Avi Kivity a...@redhat.com [2012-10-04 17:00:28]:
On 10/04/2012 03:07 PM, Peter Zijlstra wrote:
On Thu, 2012-10-04 at 14:41 +0200, Avi Kivity wrote:
Again the numbers are ridiculously
On 10/10/2012 11:33 PM, David Ahern wrote:
On 10/10/12 11:54 AM, Raghavendra K T wrote:
No, I did something like this
perf kvm --guestvmlinux ./vmlinux.guest top -g -U -d 3. Yes that is a
good idea.
(I am getting some segfaults with perf top, I think it is already fixed
but yet to see
On 10/11/2012 12:57 AM, Andrew Theurer wrote:
On Wed, 2012-10-10 at 23:13 +0530, Raghavendra K T wrote:
On 10/10/2012 07:54 PM, Andrew Theurer wrote:
I ran 'perf sched map' on the dbench workload for medium and large VMs,
and I thought I would share some of the results. I think it helps
of exporting nrrunning and optimize in core scheduler
(Peter)
- Use yield() instead of schedule in overcommit scenarios (Rik)
- Use loadavg knowledge to detect undercommit/overcommit
Peter Zijlstra (1):
Bail out of yield_to when source and target runqueue has one task
Raghavendra K T (2):
Handle
to quickly come
out of PLE handler.
Signed-off-by: Peter Zijlstra pet...@infradead.org
Raghavendra, Checking the rq length of target vcpu condition added.
Reviewed-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
kernel/sched
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Also we do not update last boosted vcpu in failure cases.
Reviewed-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
virt/kvm/kvm_main.c | 21 +++--
1
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
The patch indroduces a helper function that calculates the system load
(idea borrowed from loadavg calculation). The load is normalized to
2048 i.e., return value (threshold) of 2048 implies an approximate 1:1
committed guest
Handle yield_to failure return code for potential undercommit case
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
yield_to returns -ESRCH when When source and target of yield_to
run queue length is one. When we see two successive failures of
yield_to we assume we are in potential
-9.63721
Result shows improvement for 1x ebizzy case.
Comments/suggestions welcome.
8
kvm: Add dynamic ple window feature
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
The current value of PLE window is tuned very well for overcommited
On 10/11/2012 01:06 AM, Andrew Theurer wrote:
On Wed, 2012-10-10 at 23:24 +0530, Raghavendra K T wrote:
On 10/10/2012 08:29 AM, Andrew Theurer wrote:
On Wed, 2012-10-10 at 00:21 +0530, Raghavendra K T wrote:
* Avi Kivity a...@redhat.com [2012-10-04 17:00:28]:
On 10/04/2012 03:07 PM, Peter
On 07/13/2012 01:32 AM, Christian Borntraeger wrote:
On 12/07/12 21:18, Raghavendra K T wrote:
+#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
[...]
+ struct {
+ bool cpu_relax_intercepted;
+ bool dy_eligible;
+ } ple;
+#endif
[...]
}
vcpu
On 07/13/2012 11:43 AM, Christian Borntraeger wrote:
On 13/07/12 05:35, Raghavendra K T wrote:
maybe define static inline access functions in kvm_host.h that are no-ops
if CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT is not set.
As I already said, can you have a look at using access functions?
Yes
On 07/13/2012 07:24 PM, Srikar Dronamraju wrote:
On 12/07/12 21:18, Raghavendra K T wrote:
+#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
[...]
+ struct {
+ bool cpu_relax_intercepted;
+ bool dy_eligible;
+ } ple;
+#endif
[...]
}
vcpu-run
30%, 6% for 1x,2x respectively
ebizzyimproves by around 87%, 23% for 1x,2x respectively
Note: The patches are tested on x86.
Links
V1: https://lkml.org/lkml/2012/7/9/32
V2: https://lkml.org/lkml/2012/7/10/392
V3: https://lkml.org/lkml/2012/7/12/437
Raghavendra K T (3
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Noting pause loop exited vcpu or cpu relax intercepted helps in
filtering right candidate to yield. Wrong selection of vcpu;
i.e., a vcpu that just did a pl-exit or cpu relax intercepted may
contribute to performance degradation.
Signed-off
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Suggested-by: Avi Kivity a...@redhat.com
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
arch/s390/kvm/Kconfig |1 +
arch/x86/kvm/Kconfig |1 +
virt/kvm/Kconfig |3 +++
3 files changed, 5 insertions
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Currently, on a large vcpu guests, there is a high probability of
yielding to the same vcpu who had recently done a pause-loop exit or
cpu relax intercepted. Such a yield can lead to the vcpu spinning
again and hence degrade the performance
On 07/16/2012 09:40 PM, Rik van Riel wrote:
On 07/16/2012 06:07 AM, Avi Kivity wrote:
+{
+ bool eligible;
+
+ eligible = !vcpu-ple.cpu_relax_intercepted ||
+ (vcpu-ple.cpu_relax_intercepted
+ vcpu-ple.dy_eligible);
+
+ if (vcpu-ple.cpu_relax_intercepted)
+ vcpu-ple.dy_eligible =
On 07/16/2012 03:31 PM, Avi Kivity wrote:
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
Noting pause loop exited vcpu or cpu relax intercepted helps in
filtering right candidate to yield. Wrong selection of vcpu;
i.e., a vcpu that just
On 07/16/2012 03:37 PM, Avi Kivity wrote:
On 07/16/2012 11:25 AM, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
Currently, on a large vcpu guests, there is a high probability of
yielding to the same vcpu who had recently done a pause-loop exit or
cpu relax
On 07/17/2012 01:52 PM, Avi Kivity wrote:
On 07/16/2012 08:24 PM, Raghavendra K T wrote:
So are you saying allow vcpu to spin in non over-commit scenarios? So
that we avoid all yield_to etc...
( Or even in some other place where it is useful).
When is yielding useful, if you're
On 07/17/2012 01:59 PM, Avi Kivity wrote:
On 07/16/2012 07:10 PM, Rik van Riel wrote:
On 07/16/2012 06:07 AM, Avi Kivity wrote:
+{
+bool eligible;
+
+eligible = !vcpu-ple.cpu_relax_intercepted ||
+(vcpu-ple.cpu_relax_intercepted
+ vcpu-ple.dy_eligible);
+
+
On 07/17/2012 02:39 PM, Raghavendra K T wrote:
[...]
But
if vcpu A is spinning for x% of its time and processing on the other,
then vcpu B will flip its dy_eligible for those x%, and not flip it when
it's processing. I don't understand how this is useful.
Suppose A is doing really good job
/2012/7/12/437
V2: https://lkml.org/lkml/2012/7/10/392
V1: https://lkml.org/lkml/2012/7/9/32
Raghavendra K T (3):
config: Add config to support ple or cpu relax optimzation
kvm : Note down when cpu relax intercepted or pause loop exited
kvm : Choose a better candidate for directed
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Suggested-by: Avi Kivity a...@redhat.com
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
arch/s390/kvm/Kconfig |1 +
arch/x86/kvm/Kconfig |1 +
virt/kvm/Kconfig |3 +++
3 files changed, 5 insertions
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Currently, on a large vcpu guests, there is a high probability of
yielding to the same vcpu who had recently done a pause-loop exit or
cpu relax intercepted. Such a yield can lead to the vcpu spinning
again and hence degrade the performance
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Noting pause loop exited vcpu or cpu relax intercepted helps in
filtering right candidate to yield. Wrong selection of vcpu;
i.e., a vcpu that just did a pl-exit or cpu relax intercepted may
contribute to performance degradation.
Signed-off
On 07/18/2012 07:08 PM, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
+bool kvm_vcpu_eligible_for_directed_yield(struct kvm_vcpu *vcpu)
+{
+ bool eligible;
+
+ eligible = !vcpu-spin_loop.in_spin_loop ||
+ (vcpu
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Currently, on a large vcpu guests, there is a high probability of
yielding to the same vcpu who had recently done a pause-loop exit or
cpu relax intercepted. Such a yield can lead to the vcpu spinning
again and hence degrade the performance
(next eligible lock holder)
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
V2 was:
Reviewed-by: Rik van Riel r...@redhat.com
Changelog: Added comment on locking as suggested by Avi
include/linux/kvm_host.h |5 +
virt/kvm/kvm_main.c | 42
On 04/21/2013 03:42 AM, Jiannan Ouyang wrote:
Hello Everyone,
I recently came up with a spinlock algorithm that can adapt to
preemption, which you may be interested in.
It is overall a great and clever idea as Rik mentioned already.
The intuition is to
downgrade a fair lock to an unfair
On 04/22/2013 04:37 AM, Jiannan Ouyang wrote:
On Sun, Apr 21, 2013 at 5:12 PM, Rik van Riel r...@redhat.com wrote:
Your algorithm is very clever, and very promising.
However, it does increase the size of the struct spinlock, and adds
an additional atomic operation to spin_unlock, neither of
On 03/08/2013 12:40 AM, Marcelo Tosatti wrote:
On Mon, Mar 04, 2013 at 11:31:46PM +0530, Raghavendra K T wrote:
This patch series further filters better vcpu candidate to yield to
in PLE handler. The main idea is to record the preempted vcpus using
preempt notifiers and iterate only those
--+---+---+---++---+
no ple ebizzy 1x result for reference : 7394.9 rec/sec
Please let me know if you have any suggestions and comments.
Raghavendra K T (2):
kvm: Record the preemption status of vcpus using preempt notifiers
kvm: Iterate over only vcpus that are preempted
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Note that we mark as preempted only when vcpu's task state was
Running during preemption.
Thanks Jiannan, Avi for preemption notifier ideas. Thanks Gleb, PeterZ
for their precious suggestions. Thanks Srikar for an idea on avoiding
rcu lock
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
This helps in filtering out the eligible candidates further and
thus potentially helps in quickly allowing preempted lockholders to run.
Note that if a vcpu was spinning during preemption we filter them
by checking whether
On 03/05/2013 03:23 PM, Andrew Jones wrote:
On Mon, Mar 04, 2013 at 11:31:46PM +0530, Raghavendra K T wrote:
This patch series further filters better vcpu candidate to yield to
in PLE handler. The main idea is to record the preempted vcpus using
preempt notifiers and iterate only those
On 03/05/2013 08:49 PM, Chegu Vinod wrote:
On 3/4/2013 10:02 AM, Raghavendra K T wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Note that we mark as preempted only when vcpu's task state was
Running during preemption.
Thanks Jiannan, Avi for preemption notifier ideas. Thanks
On 11/29/2012 07:37 AM, Chegu Vinod wrote:
On 11/26/2012 4:07 AM, Raghavendra K T wrote:
In some special scenarios like #vcpu = #pcpu, PLE handler may
prove very costly, because there is no need to iterate over vcpus
and do unsuccessful yield_to burning CPU.
The first patch optimizes all
On 11/29/2012 05:46 PM, Gleb Natapov wrote:
On Wed, Nov 28, 2012 at 10:40:56AM +0530, Raghavendra K T wrote:
On 11/28/2012 06:42 AM, Marcelo Tosatti wrote:
Don't understand the reasoning behind why 3 is a good choice.
Here is where I came from. (explaining from scratch for
completeness
On 12/04/2012 01:26 AM, Marcelo Tosatti wrote:
On Wed, Nov 28, 2012 at 10:40:56AM +0530, Raghavendra K T wrote:
On 11/28/2012 06:42 AM, Marcelo Tosatti wrote:
Don't understand the reasoning behind why 3 is a good choice.
Here is where I came from. (explaining from scratch for
completeness
On 02/07/2013 04:55 PM, Stefano Stabellini wrote:
On Wed, 6 Feb 2013, Rik van Riel wrote:
Modern Intel and AMD CPUs will trap to the host when the guest
is spinning on a spinlock, allowing the host to schedule in
something else.
This effectively means the host is taking care of spinlock
* Ingo Molnar mi...@kernel.org [2013-01-24 11:32:13]:
* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote:
From: Peter Zijlstra pet...@infradead.org
In case of undercomitted scenarios, especially in large guests
yield_to overhead is significantly high. when run queue length
On 01/25/2013 04:17 PM, Ingo Molnar wrote:
* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote:
* Ingo Molnar mi...@kernel.org [2013-01-24 11:32:13]:
* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote:
From: Peter Zijlstra pet...@infradead.org
In case of undercomitted
On 01/25/2013 04:35 PM, Andrew Jones wrote:
On Fri, Jan 25, 2013 at 04:10:25PM +0530, Raghavendra K T wrote:
* Ingo Molnar mi...@kernel.org [2013-01-24 11:32:13]:
* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote:
From: Peter Zijlstra pet...@infradead.org
In case of undercomitted
On 01/26/2013 12:19 AM, Ingo Molnar wrote:
* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote:
On 01/25/2013 04:17 PM, Ingo Molnar wrote:
* Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote:
* Ingo Molnar mi...@kernel.org [2013-01-24 11:32:13]:
* Raghavendra K T
of patch 5 which limits the delay loops to 16,
I am no more seeing the degradation in virtual guests as reported
earlier, but improvements.
For the whole series:
Reviewed-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
...@infradead.org
Raghavendra, Checking the rq length of target vcpu condition added.(thanks Avi)
Reviewed-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Acked-by: Andrew Jones drjo...@redhat.com
Tested-by: Chegu Vinod chegu_vi...@hp.com
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
yield_to returns -ESRCH, When source and target of yield_to
run queue length is one. When we see three successive failures of
yield_to we assume we are in potential undercommit case and abort
from PLE handler.
The assumption is backed by low
task
Raghavendra K T (1):
Handle yield_to failure return for potential undercommit case
Please let me know your comments and suggestions.
Link for the discussion of V3 original:
https://lkml.org/lkml/2012/11/26/166
Link for V2:
https://lkml.org/lkml/2012/10/29/287
Link for V1:
https
On 01/23/2013 07:27 PM, Andrew Jones wrote:
On Tue, Jan 22, 2013 at 01:08:54PM +0530, Raghavendra K T wrote:
In some special scenarios like #vcpu = #pcpu, PLE handler may
prove very costly, because there is no need to iterate over vcpus
and do unsuccessful yield_to burning CPU.
The first
CCing PeterZ also.
On 09/07/2012 06:41 PM, Andrew Theurer wrote:
I have noticed recently that PLE/yield_to() is still not that scalable
for really large guests, sometimes even with no CPU over-commit. I have
a small change that make a very big difference.
First, let me explain what I saw:
On 09/08/2012 01:12 AM, Andrew Theurer wrote:
On Fri, 2012-09-07 at 23:36 +0530, Raghavendra K T wrote:
CCing PeterZ also.
On 09/07/2012 06:41 PM, Andrew Theurer wrote:
I have noticed recently that PLE/yield_to() is still not that scalable
for really large guests, sometimes even with no CPU
On 09/10/2012 10:42 PM, Peter Zijlstra wrote:
On Mon, 2012-09-10 at 22:26 +0530, Srikar Dronamraju wrote:
+static bool __yield_to_candidate(struct task_struct *curr, struct task_struct
*p)
+{
+ if (!curr-sched_class-yield_to_task)
+ return false;
+
+ if (curr-sched_class !=
On 09/11/2012 01:42 AM, Andrew Theurer wrote:
On Mon, 2012-09-10 at 19:12 +0200, Peter Zijlstra wrote:
On Mon, 2012-09-10 at 22:26 +0530, Srikar Dronamraju wrote:
+static bool __yield_to_candidate(struct task_struct *curr, struct task_struct
*p)
+{
+ if (!curr-sched_class-yield_to_task)
+
On 09/19/2012 01:54 AM, David Rientjes wrote:
On Tue, 18 Sep 2012, Konrad Rzeszutek Wilk wrote:
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 2340f69..309b235 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -524,6 +524,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_blob);
struct
On 09/19/2012 02:19 AM, Linus Torvalds wrote:
On Tue, Sep 18, 2012 at 1:37 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
30 words. ~360 + 29 spaces + NULL = 390?
Just allocate the max then. That's tiny.
And it's actually just 330: max ten characters for an unsigned 32-bit number.
On 09/19/2012 12:23 AM, Dave Jones wrote:
On Tue, Sep 18, 2012 at 11:38:44AM -0700, Linus Torvalds wrote:
Quoting the entire email, since I added Greg to the list of people (as
the documented maintainer of debugfs) along with what I think are the
guilty parties.
Dave, is
On 09/20/2012 03:19 AM, David Rientjes wrote:
On Wed, 19 Sep 2012, David Rientjes wrote:
From 0806b133b5b28081adf23d0d04a99636ed3b861b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilkkonrad.w...@oracle.com
Date: Wed, 19 Sep 2012 11:23:01 -0400
Subject: [PATCH 1/2] debugfs: Add lock for
1 - 100 of 1108 matches
Mail list logo
