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,
On Fri, 2012-10-19 at 14:00 +0530, Raghavendra K T wrote:
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,
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 disabled case).
Let me know if you
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 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, Raghavendra K T wrote:
* Avi Kivity
On Wed, 10 Oct 2012 09:24:55 -0500, Andrew Theurer
haban...@linux.vnet.ibm.com wrote:
Below is again 8 x 20-way VMs, but this time I tried out Nikunj's gang
scheduling patches. While I am not recommending gang scheduling, I
think it's a good data point. The performance is 3.88x the PLE
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 to
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/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 the patch that fixes)
What version of perf:
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 the
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 to
visualize what's going on regarding the
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 Zijlstra wrote:
On Thu, 2012-10-04 at 14:41
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 output from 'perf
sched map' (and perf data
* 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 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 high for arch_local_irq_restore.
On 10/05/2012 10:36 AM, Raghavendra K T wrote:
You can store i in the vcpu itself:
set_bit(vcpu-index, kvm-preempted);
This will make the fact that vcpus are stored in an array into API
instead of implementation detail :( There were patches for vcpu
destruction that changed the array to
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 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 of
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, Avi Kivity wrote:
On 09/28/2012 08:16
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/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 increasing ple_window, and results does not
seem to
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
interrupt, I can't believe we're spending 84% of the time running the
popf instruction.
Smells like a
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 of 2-4.
Hi Avi,
I ran different
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
interrupt, I can't believe we're spending 84% of the time
* 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 is
* 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;
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, Avi Kivity wrote:
On 09/28/2012 08:16 AM, Raghavendra K T wrote:
+struct pv_sched_info {
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.
Thanks for testing! Comments below.
On 09/28/2012 08:18 PM, Konrad Rzeszutek Wilk wrote:
PLE:
- works for unmodified / non-Linux guests
- works for all types of spins (e.g. smp_call_function*())
- utilizes an existing hardware interface (PAUSE instruction) so likely
more robust compared to a software interface
PV:
-
On 09/28/2012 08:16 AM, Raghavendra K T wrote:
+struct pv_sched_info {
+ unsigned long sched_bitmap;
Thinking, whether we need something similar to cpumask here?
Only thing is we are representing guest (v)cpumask.
DECLARE_BITMAP(sched_bitmap, KVM_MAX_VCPUS)
cpumask is
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;
Thinking, whether we need something similar to cpumask here?
Only thing is we are representing guest
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;
Thinking, whether we need something similar to cpumask here?
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
PLE:
- works for unmodified / non-Linux guests
- works for all types of spins (e.g. smp_call_function*())
- utilizes an existing hardware interface (PAUSE instruction) so likely
more robust compared to a software interface
PV:
- has more information, so it can perform better
On Tue, Sep 25, 2012 at 10:54:21AM +0200, 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)
On 09/25/2012 04:21 PM, Takuya Yoshikawa wrote:
On Tue, 25 Sep 2012 10:12:49 +0200
Avi Kivity a...@redhat.com wrote:
It will. The tradeoff is between false-positive costs (undercommit) and
true positive costs (overcommit). I think undercommit should perform
well no matter what.
If we
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 lock holder is preempted or not before
On 09/27/2012 09:44 AM, Gleb Natapov wrote:
On Tue, Sep 25, 2012 at 10:54:21AM +0200, 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
On Thu, Sep 27, 2012 at 10:59:21AM +0200, Avi Kivity wrote:
On 09/27/2012 09:44 AM, Gleb Natapov wrote:
On Tue, Sep 25, 2012 at 10:54:21AM +0200, 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
On 09/27/2012 11:11 AM, Gleb Natapov wrote:
User return notifier is per-cpu, not per-task. There is a new task_work
(linux/task_work.h) that does what you want. With these
technicalities out of the way, I think it's the wrong idea. If a vcpu
thread is in userspace, that doesn't mean it's
On Thu, Sep 27, 2012 at 11:33:56AM +0200, Avi Kivity wrote:
On 09/27/2012 11:11 AM, Gleb Natapov wrote:
User return notifier is per-cpu, not per-task. There is a new task_work
(linux/task_work.h) that does what you want. With these
technicalities out of the way, I think it's the wrong
On 09/27/2012 11:58 AM, Gleb Natapov wrote:
btw, we can have secondary effects. A vcpu can be waiting for a lock in
the host kernel, or for a host page fault. There's no point in boosting
anything for that. Or a vcpu in userspace can be waiting for a lock
that is held by another
On Thu, Sep 27, 2012 at 12:04:58PM +0200, Avi Kivity wrote:
On 09/27/2012 11:58 AM, Gleb Natapov wrote:
btw, we can have secondary effects. A vcpu can be waiting for a lock in
the host kernel, or for a host page fault. There's no point in boosting
anything for that. Or a vcpu
On 09/27/2012 12:08 PM, Gleb Natapov wrote:
On Thu, Sep 27, 2012 at 12:04:58PM +0200, Avi Kivity wrote:
On 09/27/2012 11:58 AM, Gleb Natapov wrote:
btw, we can have secondary effects. A vcpu can be waiting for a lock
in
the host kernel, or for a host page fault. There's no
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 01:26 PM, Raghavendra K T wrote:
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
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 or
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/25/2012 09:36 AM, Raghavendra K T wrote:
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
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 that checking rq1 length is not proper in
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 Tue, 25 Sep 2012 10:12:49 +0200
Avi Kivity a...@redhat.com wrote:
It will. The tradeoff is between false-positive costs (undercommit) and
true positive costs (overcommit). I think undercommit should perform
well no matter what.
If we utilize preempt notifiers to track overcommit
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.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of
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/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 is less than or equal to physical
CPUs,
PLE exits become
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 trouble here.
On Mon, 2012-09-24 at 18:06 +0200, Avi Kivity wrote:
We would probably need a -sched_exit() preempt notifier to make this
work. Peter, I know how much you love those, would it be acceptable?
Where exactly do you want this? TASK_DEAD? or another exit?
--
To unsubscribe from this list: send
On 09/24/2012 06:14 PM, Peter Zijlstra wrote:
On Mon, 2012-09-24 at 18:06 +0200, Avi Kivity wrote:
We would probably need a -sched_exit() preempt notifier to make this
work. Peter, I know how much you love those, would it be acceptable?
Where exactly do you want this? TASK_DEAD? or
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, and
trying to find a target VCPU to yield_to just
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, and
63 matches
Mail list logo
