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
