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
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 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
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
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
* 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
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
knowledge to detect undercommit/overcommit
Peter Zijlstra (1):
Bail out of yield_to when source and target runqueue has one task
Raghavendra K T (1):
Handle yield_to failure return for potential undercommit case
Please let me know your comments and suggestions.
Link for V2:
https://lkml.org
...@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
---
kernel/sched/core.c | 25 +++--
1 file changed, 19 insertions
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
On 11/26/2012 07:13 PM, Andrew Jones wrote:
On Mon, Nov 26, 2012 at 05:38:04PM +0530, Raghavendra K T wrote:
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
On 11/26/2012 07:05 PM, Andrew Jones wrote:
On Mon, Nov 26, 2012 at 05:37:54PM +0530, Raghavendra K T 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 of
source
the result for 1.5x overcommit will post the
result.
On Mon, Nov 26, 2012 at 05:38:04PM +0530, Raghavendra K T wrote:
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
On 11/27/2012 07:34 PM, Andrew Theurer wrote:
On Tue, 2012-11-27 at 16:00 +0530, Raghavendra K T wrote:
On 11/26/2012 07:05 PM, Andrew Jones wrote:
On Mon, Nov 26, 2012 at 05:37:54PM +0530, Raghavendra K T wrote:
From: Peter Zijlstra pet...@infradead.org
In case of undercomitted scenarios
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 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
[I forgot to do TO to Ingo last time]
Ingo,
Could you please take this into x86 tree.
This is
Acked-by: Andrew Jones drjo...@redhat.com
Tested-by: Chegu Vinod chegu_vi...@hp.com
Marcelo, do you want to add your Acked-by/Reviewed-by?
On 12/14/2012 09:10 PM, Raghavendra K T wrote:
Hi Ingo
On 08/10/2012 12:01 AM, Marcelo Tosatti wrote:
On Tue, Aug 07, 2012 at 01:09:46PM +0530, Raghavendra K T wrote:
This is the hypercall documentation patch series
First patch covers KVM specific hypercall information.
second patch is has typo fix for vmcall instruction
comment in kvm_para.h
(after wrapping)
Thanks Nikunj for his quick verification of the patch.
Please let me know if this patch is interesting and makes sense.
8
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Currently we use next vcpu to last boosted vcpu as starting point
while deciding
On 09/02/2012 09:59 PM, Rik van Riel wrote:
On 09/02/2012 06:12 AM, Gleb Natapov wrote:
On Thu, Aug 30, 2012 at 12:51:01AM +0530, Raghavendra K T wrote:
The idea of starting from next vcpu (source of yield_to + 1) seem to
work
well for overcomitted guest rather than using last boosted vcpu. We
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)
+
* Andrew Theurer haban...@linux.vnet.ibm.com [2012-09-11 13:27:41]:
On Tue, 2012-09-11 at 11:38 +0530, Raghavendra K T wrote:
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
On 09/02/2012 09:59 PM, Rik van Riel wrote:
On 09/02/2012 06:12 AM, Gleb Natapov wrote:
On Thu, Aug 30, 2012 at 12:51:01AM +0530, Raghavendra K T wrote:
The idea of starting from next vcpu (source of yield_to + 1) seem to
work
well for overcomitted guest rather than using last boosted vcpu. We
On 09/14/2012 10:40 PM, Andrew Jones wrote:
On Thu, Sep 13, 2012 at 04:30:58PM -0500, Andrew Theurer wrote:
On Thu, 2012-09-13 at 17:18 +0530, Raghavendra K T wrote:
* Andrew Theurerhaban...@linux.vnet.ibm.com [2012-09-11 13:27:41]:
[...]
On picking a better vcpu to yield to: I really
On 09/13/2012 02:48 AM, Jiannan Ouyang wrote:
Hi Raghu,
I'm working on improving paravirtualized spinlock performance for a
while, with my past findings, I come up with a new idea to make the
pause-loop handler more efficient.
Our original idea is to expose vmm scheduling information to the
to other VMs to run.
Raghavendra K T(2):
Handle undercommitted guest case in PLE handler
Be courteous to other VMs in overcommitted scenario in PLE handler
Results:
base = 3.6.0-rc5 + ple handler optimization patches from kvm tree.
patched = base + patch1 + patch2
machine: x240 with 16 core
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
When total number of VCPUs of system is less than or equal to physical CPUs,
PLE exits become costly since each VCPU can have dedicated PCPU, and
trying to find a target VCPU to yield_to just burns time in PLE handler.
This patch reduces
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
When PLE handler fails to find a better candidate to yield_to, it
goes back and does spin again. This is acceptable when we do not
have overcommit.
But in overcommitted scenarios (especially when we have large
number of small guests
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 is less than or equal to physical
CPUs,
PLE exits become costly since each VCPU can have dedicated PCPU
On 09/21/2012 07:22 PM, Rik van Riel wrote:
On 09/21/2012 09:46 AM, Takuya Yoshikawa wrote:
On Fri, 21 Sep 2012 17:30:20 +0530
Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote:
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
When PLE handler fails to find a better candidate
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/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
On 09/28/2012 05:10 PM, Andrew Theurer wrote:
On Fri, 2012-09-28 at 11:08 +0530, Raghavendra K T wrote:
On 09/27/2012 05:33 PM, Avi Kivity wrote:
On 09/27/2012 01:23 PM, Raghavendra K T wrote:
[...]
Also there may be a lot of false positives (deferred preemptions even
when
* 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
* 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 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 05/30/2012 05:24 PM, Jan Kiszka wrote:
On 2012-05-02 12:09, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
KVM_HC_KICK_CPU hypercall added to wakeup halted vcpu in paravirtual spinlock
enabled guest.
KVM_FEATURE_PV_UNHALT enables guest to check whether pv
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Thanks Alex for KVM_HC_FEATURES inputs and Jan for VAPIC_POLL_IRQ
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
diff --git a/Documentation/virtual/kvm/hypercalls.txt
b/Documentation/virtual/kvm/hypercalls.txt
new
On 06/04/2012 09:30 AM, Rob Landley wrote:
On 05/31/2012 12:46 PM, H. Peter Anvin wrote:
On 05/31/2012 01:01 AM, Raghavendra K T wrote:
+
+TODO:
+1. more information on input and output needed?
+2. Add more detail to purpose of hypercalls.
1. definitely, including the hypercall ABI
On 05/31/2012 11:14 PM, Randy Dunlap wrote:
On 05/31/2012 01:01 AM, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
Thanks Alex for KVM_HC_FEATURES inputs and Jan for VAPIC_POLL_IRQ
Signed-off-by: Raghavendra K Traghavendra...@linux.vnet.ibm.com
---
diff --git
On 05/30/2012 04:56 PM, Raghavendra K T wrote:
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
In ple handler code, last_boosted_vcpu (lbv) variable is
serving as reference point to start when we enter.
lbv = kvm-lbv;
for each vcpu i of kvm
if i is eligible
if yield_to(i) is success
lbv = i
currently this variable is per VM and it is set after we do
On 06/20/2012 02:21 AM, Rik van Riel wrote:
On Wed, 20 Jun 2012 01:50:50 +0530
Raghavendra K Traghavendra...@linux.vnet.ibm.com wrote:
In ple handler code, last_boosted_vcpu (lbv) variable is
serving as reference point to start when we enter.
Also statistical analysis (below) is showing
On 06/21/2012 12:13 PM, Gleb Natapov wrote:
On Tue, Jun 19, 2012 at 04:51:04PM -0400, Rik van Riel wrote:
On Wed, 20 Jun 2012 01:50:50 +0530
Raghavendra K Traghavendra...@linux.vnet.ibm.com wrote:
In ple handler code, last_boosted_vcpu (lbv) variable is
serving as reference point to start
On 06/21/2012 01:42 AM, Raghavendra K T wrote:
On 06/20/2012 02:21 AM, Rik van Riel wrote:
On Wed, 20 Jun 2012 01:50:50 +0530
Raghavendra K Traghavendra...@linux.vnet.ibm.com wrote:
[...]
Please let me know how it goes.
Yes, have got result today, too tired to summarize. got better
On 06/22/2012 08:41 PM, Andrew Jones wrote:
On Thu, Jun 21, 2012 at 04:56:08PM +0530, Raghavendra K T wrote:
Here are the results from kernbench.
PS: I think we have to only take that, both the patches perform better,
than reading into actual numbers since I am seeing more variance
On 06/23/2012 02:30 AM, Raghavendra K T wrote:
On 06/22/2012 08:41 PM, Andrew Jones wrote:
On Thu, Jun 21, 2012 at 04:56:08PM +0530, Raghavendra K T wrote:
Here are the results from kernbench.
PS: I think we have to only take that, both the patches perform better,
than reading into actual
On 06/24/2012 12:04 AM, Raghavendra K T wrote:
On 06/23/2012 02:30 AM, Raghavendra K T wrote:
On 06/22/2012 08:41 PM, Andrew Jones wrote:
[...]
My run for other benchmarks did not have Rik's patches, so re-spinning
everything with that now.
Here is the detailed info on env and benchmark I am
On 06/28/2012 01:57 AM, Raghavendra K T wrote:
On 06/24/2012 12:04 AM, Raghavendra K T wrote:
On 06/23/2012 02:30 AM, Raghavendra K T wrote:
On 06/22/2012 08:41 PM, Andrew Jones wrote:
[...]
(benchmark values will be attached in reply to this mail)
pv_benchmark_summary.bz2
Description
On 06/21/2012 12:13 PM, Gleb Natapov wrote:
On Tue, Jun 19, 2012 at 04:51:04PM -0400, Rik van Riel wrote:
On Wed, 20 Jun 2012 01:50:50 +0530
Raghavendra K Traghavendra...@linux.vnet.ibm.com wrote:
In ple handler code, last_boosted_vcpu (lbv) variable is
serving as reference point to start
On 06/28/2012 09:30 PM, Andrew Jones wrote:
- Original Message -
In summary, current PV has huge benefit on non-PLE machine.
On PLE machine, the results become very sensitive to load, type of
workload and SPIN_THRESHOLD. Also PLE interference has significant
effect on them. But still
On 04/27/2012 09:23 PM, Gleb Natapov wrote:
On Fri, Apr 27, 2012 at 04:15:35PM +0530, Raghavendra K T wrote:
On 04/24/2012 03:29 PM, Gleb Natapov wrote:
On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
From: Srivatsa Vaddagiriva...@linux.vnet.ibm.com
KVM_HC_KICK_CPU allows
On 07/02/2012 08:19 PM, Rik van Riel wrote:
On 06/28/2012 06:55 PM, Vinod, Chegu wrote:
Hello,
I am just catching up on this email thread...
Perhaps one of you may be able to help answer this query.. preferably
along with some data. [BTW, I do understand the basic intent behind
PLE in a
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Noting pause loop exited vcpu helps in filtering right candidate to yield.
Yielding to same vcpu may result in more wastage of cpu.
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
arch/x86/include/asm/kvm_host.h |7
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Currently PLE handler can repeatedly do a directed yield to same vcpu
that has recently done PL exit. This can degrade the performance
Try to yield to most eligible guy instead, by alternate yielding.
Precisely, give chance to a VCPU which
%
+---+---+---++---+
kernbench 1x: 4 fast runs = 12 runs avg
kernbench 2x: 4 fast runs = 12 runs avg
sysbench 1x: 8runs avg
sysbench 2x: 8runs avg
ebizzy 1x: 8runs avg
ebizzy 2x: 8runs avg
Thanks Vatsa and Srikar for brainstorming discussions regarding
optimizations.
Raghavendra K T (2):
kvm
1 - 100 of 558 matches
Mail list logo
