All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: "Hu, Xuekun" <xuekun.hu@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Patch]KVM: enabling per domain PLE
Date: Wed, 17 Oct 2012 12:11:50 +0200	[thread overview]
Message-ID: <507E8466.7040205@redhat.com> (raw)
In-Reply-To: <88A92D351643BA4CB23E3031551706260FD9315E@SHSMSX102.ccr.corp.intel.com>

On 10/17/2012 10:02 AM, Hu, Xuekun wrote:
>> 
>> The problem with this is that it requires an administrator to understand the
>> workload, not only of the guest, but also of other guests on the machine.
>> With low overcommit, a high PLE window reduces unneeded exits, but with
>> high overcommit we need those exits to reduce spinning.
>> 
>> In addition, most kvm hosts don't have an administrator.  They are controlled
>> by a management system, which means we'll need some algorithm in
>> userspace to control the PLE window.  Taking the two together, we need a
>> dynamic (for changing workloads) algorithm.
>> 
>> There are threads discussing this dynamic algorithm, we are making slow
>> progress because it's such a difficult problem, but I think this is much more
>> useful than anything requiring user intervention.
> 
> Avi, agreed that dynamic adaptive ple should be the best solution. However
> currently it is a difficult problem like you said. Our solution just gives user
> a choice who know how to set the two PLE values. So the solution is a compromise
> solution, which should be better than nothing, for now? :-)

Let's see how the PLE thread works out.  Yes the patches give the user
control, but we need to make sure the user knows how to control it (in
fact your patch doesn't even update the documentation).  Just throwing
out a new ioctl, even if it is documented, doesn't mean that userspace
will begin to use it, or that users will exploit it.

Do you have a specific use case in mind?

-- 
error compiling committee.c: too many arguments to function

WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: "Hu, Xuekun" <xuekun.hu@intel.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [Patch]KVM: enabling per domain PLE
Date: Wed, 17 Oct 2012 12:11:50 +0200	[thread overview]
Message-ID: <507E8466.7040205@redhat.com> (raw)
In-Reply-To: <88A92D351643BA4CB23E3031551706260FD9315E@SHSMSX102.ccr.corp.intel.com>

On 10/17/2012 10:02 AM, Hu, Xuekun wrote:
>> 
>> The problem with this is that it requires an administrator to understand the
>> workload, not only of the guest, but also of other guests on the machine.
>> With low overcommit, a high PLE window reduces unneeded exits, but with
>> high overcommit we need those exits to reduce spinning.
>> 
>> In addition, most kvm hosts don't have an administrator.  They are controlled
>> by a management system, which means we'll need some algorithm in
>> userspace to control the PLE window.  Taking the two together, we need a
>> dynamic (for changing workloads) algorithm.
>> 
>> There are threads discussing this dynamic algorithm, we are making slow
>> progress because it's such a difficult problem, but I think this is much more
>> useful than anything requiring user intervention.
> 
> Avi, agreed that dynamic adaptive ple should be the best solution. However
> currently it is a difficult problem like you said. Our solution just gives user
> a choice who know how to set the two PLE values. So the solution is a compromise
> solution, which should be better than nothing, for now? :-)

Let's see how the PLE thread works out.  Yes the patches give the user
control, but we need to make sure the user knows how to control it (in
fact your patch doesn't even update the documentation).  Just throwing
out a new ioctl, even if it is documented, doesn't mean that userspace
will begin to use it, or that users will exploit it.

Do you have a specific use case in mind?

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-10-17 10:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-16  6:53 [Patch]KVM: enabling per domain PLE Hu, Xuekun
2012-10-16  6:53 ` [Qemu-devel] " Hu, Xuekun
2012-10-16  9:24 ` Avi Kivity
2012-10-16  9:24   ` [Qemu-devel] " Avi Kivity
2012-10-17  8:02   ` Hu, Xuekun
2012-10-17  8:02     ` [Qemu-devel] " Hu, Xuekun
2012-10-17 10:11     ` Avi Kivity [this message]
2012-10-17 10:11       ` Avi Kivity
2012-10-18  9:11       ` Hu, Xuekun
2012-10-18  9:11         ` [Qemu-devel] " Hu, Xuekun
2012-10-29 12:43       ` Hu, Xuekun
2012-10-29 12:43         ` [Qemu-devel] " Hu, Xuekun

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=507E8466.7040205@redhat.com \
    --to=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=xiantao.zhang@intel.com \
    --cc=xuekun.hu@intel.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.