From mboxrd@z Thu Jan 1 00:00:00 1970 From: Emmanuel Ackaouy Subject: Re: credit scheduler and HYPERVISOR_yield() Date: Tue, 9 Oct 2007 16:48:42 +0200 Message-ID: <368868960d399c52030f43aa3e74ff6f@gmail.com> References: <20071008234118.GA1396@totally.trollied.org.uk> <7e903d73fbea1bb8ca97396fef058b2b@gmail.com> <20071009121533.GA30258@totally.trollied.org.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap Cc: xen-devel@lists.xensource.com, John Levon List-Id: xen-devel@lists.xenproject.org On Oct 9, 2007, at 15:22, George Dunlap wrote: > What this means in the case of a yield(), unfortunately, is that If a > given vcpu is the only vcpu on its processor with credits left, all it > can do is burn up its extra credits spinning or calling yield() to no > effect. > > A simple option would be, for the credit scheduler, to temporarily > reduce the priority from TS_UNDER to TS_OVER. This will cause it to > actually yield if there's any other vcpus that can run. The next time > accounting is done, the priority will be reset, and it should get more > time because of the time it's given up. Temporarily changing the priority to TS_OVER strikes me as a reasonable idea. However, changing it for an average of half of the accounting period (1/2 100ms = 50ms) is hardly "temporary". A VCPUs that would call yield() more than once every 50ms or so -- which isn't unreasonable -- would never be able to run at TS_UNDER. That would totally distort accounting fairness for users of yield(). Maybe something more in the temporary spirit of the TS_BOOST priority (but lower not higher than TS_UNDER) would be better? It may be worthwhile to consider if yield() can be replaced with more intelligent mechanisms for VCPU synchronization of SMP guests. In the case of ACKed IPIs for example, if all target VCPUs are not running at the time of the IPI initiation, it might be a good idea to put the source to sleep until all targets have ACKed. If all target VCPUs are running though, I suspect things will work best if the IPI initiator does not yield at all.