WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] credit scheduler and HYPERVISOR_yield()

To: "George Dunlap" <gdunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] credit scheduler and HYPERVISOR_yield()
From: Emmanuel Ackaouy <ackaouy@xxxxxxxxx>
Date: Tue, 9 Oct 2007 16:48:42 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 09 Oct 2007 07:49:17 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:content-transfer-encoding:cc:from:subject:date:to:x-mailer; bh=20ogLzwR7ahgsWhVGKRKUZNac7Nz1jT5I1Lnl/DRiWA=; b=Q4TaHm13NcqRPxOksaj5lNkfOoKqWEjBAatkqSHnGvR25qBdQnAP16rYznogI3J9m2NtpXklhpNm4qPhqklaiExcwq3sf+x+KIcRcbR0s20+XbWqpoi9UCNFL2ndppL1c0HqiPim8eoKDJ6GfGL3H2J9aWw0FtLrOtSMqHrn0kI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=LZLai88mupBYHdiCg+cKLspd9wIapoBg++Xs+c7Cb6l7ok63fx2XhTmKPNAuDAqZ2opPmjL+BuKvvJG0+HE/HGtuBfrPpTGAHNsphn9BJS98UgGMM1fgGfjsQ5TN31l0v3psWIuXvgwpnpw/wAqosuIjqkFFHYH+ncthshIvWhM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0710090622x63a1c34exc7a14c391782211b@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20071008234118.GA1396@xxxxxxxxxxxxxxxxxxxxxxx> <7e903d73fbea1bb8ca97396fef058b2b@xxxxxxxxx> <20071009121533.GA30258@xxxxxxxxxxxxxxxxxxxxxxx> <de76405a0710090622x63a1c34exc7a14c391782211b@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel