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 13:57:37 +0200 Message-ID: <4D060A31.3030606@redhat.com> References: <20101202144129.4357fe00@annuminas.surriel.com> <20101210050344.GR3158@balbir.in.ibm.com> <4D0328CC.1020809@redhat.com> <20101211135727.GU3158@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: <20101211135727.GU3158@balbir.in.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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. -- error compiling committee.c: too many arguments to function