All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: "Vinod, Chegu" <chegu_vinod@hp.com>
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Andrew Jones <drjones@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Srikar <srikar@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Gleb Natapov <gleb@redhat.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Avi Kivity <avi@redhat.com>, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH] kvm: handle last_boosted_vcpu = 0 case
Date: Mon, 02 Jul 2012 10:49:08 -0400	[thread overview]
Message-ID: <4FF1B4E4.2010801@redhat.com> (raw)
In-Reply-To: <C4FA8004DBDF864387014E5EA4383B0F580BD0F5E7@GVW1336EXC.americas.hpqcorp.net>

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 typical [sweet spot] use case where there is over subscription etc. and the need to optimize the PLE handler in the host etc. ]
>
> In a use case where the host has fewer but much larger guests (say 40VCPUs and higher) and there is no over subscription (i.e. # of vcpus across guests<= physical cpus in the host  and perhaps each guest has their vcpu's pinned to specific physical cpus for other reasons), I would like to understand if/how  the PLE really helps ?  For these use cases would it be ok to turn PLE off (ple_gap=0) since is no real need to take an exit and find some other VCPU to yield to ?

Yes, that should be ok.

On a related note, I wonder if we should increase the ple_gap
significantly.

After all, 4096 cycles of spinning is not that much, when you
consider how much time is spent doing the subsequent vmexit,
scanning the other VCPU's status (200 cycles per cache miss),
deciding what to do, maybe poking another CPU, and eventually
a vmenter.

A factor 4 increase in ple_gap might be what it takes to
get the amount of time spent spinning equal to the amount of
time spent on the host side doing KVM stuff...

-- 
All rights reversed

  reply	other threads:[~2012-07-02 14:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-19 20:20 Regarding improving ple handler (vcpu_on_spin) Raghavendra K T
2012-06-19 20:51 ` [PATCH] kvm: handle last_boosted_vcpu = 0 case Rik van Riel
2012-06-20 20:12   ` Raghavendra K T
2012-06-21  2:11     ` Rik van Riel
2012-06-21 11:26     ` Raghavendra K T
2012-06-22 15:11       ` Andrew Jones
2012-06-22 21:00         ` Raghavendra K T
2012-06-23 18:34           ` Raghavendra K T
2012-06-27 20:27             ` Raghavendra K T
2012-06-27 20:29               ` [PATCH] kvm: handle last_boosted_vcpu = 0 case with benchmark detail attachment Raghavendra K T
2012-06-28 16:00               ` [PATCH] kvm: handle last_boosted_vcpu = 0 case Andrew Jones
2012-06-28 16:22                 ` Raghavendra K T
2012-06-28 22:55                   ` Vinod, Chegu
2012-06-28 22:55                     ` Vinod, Chegu
2012-07-02 14:49                     ` Rik van Riel [this message]
2012-07-03  3:30                       ` Raghavendra K T
2012-07-05 14:45                       ` Andrew Theurer
2012-06-21  6:43   ` Gleb Natapov
2012-06-21 10:23     ` Raghavendra K T
2012-06-28  2:14     ` Raghavendra K T
2012-07-06 17:11   ` Marcelo Tosatti

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=4FF1B4E4.2010801@redhat.com \
    --to=riel@redhat.com \
    --cc=avi@redhat.com \
    --cc=chegu_vinod@hp.com \
    --cc=drjones@redhat.com \
    --cc=gleb@redhat.com \
    --cc=jeremy@goop.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=raghavendra.kt@linux.vnet.ibm.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=vatsa@linux.vnet.ibm.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.