qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Patch]KVM: enabling per domain PLE


From: Hu, Xuekun
Subject: Re: [Qemu-devel] [Patch]KVM: enabling per domain PLE
Date: Thu, 18 Oct 2012 09:11:44 +0000

> -----Original Message-----
> From: Avi Kivity [mailto:address@hidden
> Sent: Wednesday, October 17, 2012 6:12 PM
> To: Hu, Xuekun
> Cc: address@hidden; address@hidden; Zhang, Xiantao
> Subject: Re: [Patch]KVM: enabling per domain PLE
> 
> 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?
> 

Yes, some cloud vendors already knew that different PLE values has big 
performance
impact on their applications. They want one interface for them to set. And I 
think the
big cloud vendors should have administrators that have experience on PLE 
tuning. :-) 

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]