From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOQbZ-0008TW-Oi for qemu-devel@nongnu.org; Wed, 17 Oct 2012 06:12:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOQbT-0008RW-Sc for qemu-devel@nongnu.org; Wed, 17 Oct 2012 06:12:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOQbT-0008RM-IJ for qemu-devel@nongnu.org; Wed, 17 Oct 2012 06:11:55 -0400 Message-ID: <507E8466.7040205@redhat.com> Date: Wed, 17 Oct 2012 12:11:50 +0200 From: Avi Kivity MIME-Version: 1.0 References: <88A92D351643BA4CB23E3031551706260FD89CC8@SHSMSX102.ccr.corp.intel.com> <507D27C5.4010905@redhat.com> <88A92D351643BA4CB23E3031551706260FD9315E@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <88A92D351643BA4CB23E3031551706260FD9315E@SHSMSX102.ccr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Patch]KVM: enabling per domain PLE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Hu, Xuekun" Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" 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