From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC PATCH 0/3] directed yield for Pause Loop Exiting Date: Mon, 13 Dec 2010 14:42:52 +0200 Message-ID: <4D0614CC.5060900@redhat.com> References: <20101202144129.4357fe00@annuminas.surriel.com> <20101210050344.GR3158@balbir.in.ibm.com> <4D0328CC.1020809@redhat.com> <20101211135727.GU3158@balbir.in.ibm.com> <4D060A31.3030606@redhat.com> <20101213123944.GA14178@balbir.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rik van Riel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Srivatsa Vaddagiri , Peter Zijlstra , Ingo Molnar , Anthony Liguori To: balbir@linux.vnet.ibm.com Return-path: In-Reply-To: <20101213123944.GA14178@balbir.in.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 12/13/2010 02:39 PM, Balbir Singh wrote: > * Avi Kivity [2010-12-13 13:57:37]: > > > On 12/11/2010 03:57 PM, Balbir Singh wrote: > > >* Avi Kivity [2010-12-11 09:31:24]: > > > > > >> On 12/10/2010 07:03 AM, Balbir Singh wrote: > > >> >> > > >> >> Scheduler people, please flame me with anything I may have done > > >> >> wrong, so I can do it right for a next version :) > > >> >> > > >> > > > >> >This is a good problem statement, there are other things to consider > > >> >as well > > >> > > > >> >1. If a hard limit feature is enabled underneath, donating the > > >> >timeslice would probably not make too much sense in that case > > >> > > >> What's the alternative? > > >> > > >> Consider a two vcpu guest with a 50% hard cap. Suppose the workload > > >> involves ping-ponging within the guest. If the scheduler decides to > > >> schedule the vcpus without any overlap, then the throughput will be > > >> dictated by the time slice. If we allow donation, throughput is > > >> limited by context switch latency. > > >> > > > > > >If the vpcu holding the lock runs more and capped, the timeslice > > >transfer is a heuristic that will not help. > > > > Why not? as long as we shift the cap as well. > > > > Shifting the cap would break it, no? The total cap for the guest would remain. > Anyway, that is something for us > to keep track of as we add additional heuristics, not a show stopper. Sure, as long as we see a way to fix it eventually. -- error compiling committee.c: too many arguments to function