> -----Original Message----- > From: Avi Kivity [mailto:avi@xxxxxxxxxx] > Sent: Wednesday, October 17, 2012 6:12 PM > To: Hu, Xuekun > Cc: kvm@xxxxxxxxxxxxxxx; qemu-devel@xxxxxxxxxx; 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
