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: "Emmanuel Ackaouy" <ackaouy@xxxxxxxxx>
Subject: Re: [Xen-devel] credit scheduler and HYPERVISOR_yield()
From: "George Dunlap" <gdunlap@xxxxxxxxxxxxx>
Date: Mon, 15 Oct 2007 13:26:06 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 15 Oct 2007 05:26:45 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=nT6s8OYUWEFnG5Y3uq+tXznoWDoZDXgmbx06oxu2TX4=; b=CvTPV7M6Elg39IXTQIAv7X8GgizY1Yp4KoEH99esaOd0MRfDuqfiyXRTyWMzNTeJA8vvvW5FieRdPdnBT86kmK7V56Y7WrAxldDbX8pmdgSBkDdASnFMwr2V+DMwVMahcqffeTWIskQ4De/nj6sr3/w0CIUm7m12w8RRc9L14bM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZazSsQDwrw1+UxJwGh6zUHBd/FDUp63SmPHHAfiWr9T5Dm3jMPhaZG7VDqTyVAl3Dxt6sx+q1OSUZBb6Ii2rv0AwQEqWt587lfRICsX/jRhZhreKTz+fEs5ol3AGgv0ZEDuBydWVvzceF/y+DgzYquHlWs99MdrdQ3ugcQq1csQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <d7a896adb8c075492604f52f257dd573@xxxxxxxxx>
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> <20071014184528.GB16827@xxxxxxxxxxxxxxxxxxxxxxx> <d7a896adb8c075492604f52f257dd573@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 10/14/07, Emmanuel Ackaouy <ackaouy@xxxxxxxxx> wrote:
> Doing the change that George proposed may help in your case
> but I suspect that, as I described in my previous post, it will cause
> problems for other workloads.
>
> I think it is reasonable for a yield() operation to yield to runnable
> VCPUs of equal or higher priority than the running VCPU. That
> is the behavior of the scheduler today. Maybe your problem can
> be addressed without changing the behavior of yield?

Part of the problem is that for the credit scheduler, the "priority"
is used a bit differently.  It changes, and it has no fundamental
relationship between more important work and less important work; it's
just a mechanism for implementing time allocations. (And a very clever
way, I might add.)

It's clear that "yield-I-really-mean-it" is useful for smp
synchronization issues (like yielding when waiting for a spinlock held
by scheduled-out vcpus, or waiting for a scheduled-out processor to
ACK an IPI).  But I can't really think of a situation where
"yield-to-other-cpus-that-haven't-used-all-their-credits-yet" is
particularly useful.  Can you think of an example?

Perhaps a better implementation of "yield-I-really-mean-it" would be:
* Reduce the priority only if there are no vcpus of the same priority
in the queue; and perhaps, only if there are no vcpus in the queue and
no work to steal.
* As soon as the vcpu in question is scheduled, raise its priority again.

That should avoid some of the problems you've pointed out with the
yield-reduces-priority technique.

> Arguably, a number of things need to be done in
> the Xen scheduler and synchronization primitives to improve
> the performance of SMP guests. It may be worthwhile to have
> a generic discussion about that on top of the specific problem
> you're encountering.

Here are some random ideas:
* Expose to the guest, via the shared-info page, which vcpus are
actively scheduled or not.
* Implement some kind of a yield or block primitive, like:
+ yield to a specific vcpu (i.e., the one holding the lock you want)
+ block with a vcpu mask.  The vcpu will then be blocked until each of
the vcpus in the mask has been scheduled at least once.

Thoughts?

 -George

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