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: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Date: Mon, 15 Oct 2007 13:43:40 +0100
Cc: Emmanuel Ackaouy <ackaouy@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 15 Oct 2007 05:44:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0710150526g3b89513dx7bfc1c62c79ba996@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>
Mail-followup-to: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>, George Dunlap <gdunlap@xxxxxxxxxxxxx>, Emmanuel Ackaouy <ackaouy@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, John Levon <levon@xxxxxxxxxxxxxxxxx>
References: <20071008234118.GA1396@xxxxxxxxxxxxxxxxxxxxxxx> <7e903d73fbea1bb8ca97396fef058b2b@xxxxxxxxx> <20071009121533.GA30258@xxxxxxxxxxxxxxxxxxxxxxx> <de76405a0710090622x63a1c34exc7a14c391782211b@xxxxxxxxxxxxxx> <20071014184528.GB16827@xxxxxxxxxxxxxxxxxxxxxxx> <d7a896adb8c075492604f52f257dd573@xxxxxxxxx> <de76405a0710150526g3b89513dx7bfc1c62c79ba996@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.12-2006-07-14
Hi,

George Dunlap, le Mon 15 Oct 2007 13:26:06 +0100, a écrit :
> 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?

That could actually be the counter part of "yield-I-really-mean-it":
- vCPU0 yields-really-means-it so as to hopefully schedule vCPU1
- vCPU1 realizes why it got scheduled, does the needed urging job.
- vCPU1 "yields-to-other-cpus-thatblabla", for letting Xen know it
  finished its urging job and usual priorities can be taken into account
  again.
- vCPU0 gets scheduled again because it actually had bigger priority.

> Here are some random ideas:
> * Expose to the guest, via the shared-info page, which vcpus are
> actively scheduled or not.

That could be useful, but one can't safely rely on it, since it may
change asynchronously.

> * Implement some kind of a yield or block primitive, like:
> + yield to a specific vcpu (i.e., the one holding the lock you want)

That should be quite fine.  Xen could use it as a strong scheduling
hint. If scheduling that vCPU immediately would break some quota rules
for instance, Xen could still remember that it shouldn't reschedule the
calling vCPU before having scheduled the target vCPU at least once.

> + 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.

That could be also called yield_to_vcpus actually.

Samuel

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