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