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/
Home Products Support Community News


RE: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding

To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding
From: Bryan S Rosenburg <rosnbrg@xxxxxxxxxx>
Date: Wed, 8 Jun 2005 14:40:40 -0400
Cc: ryanh@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, hohnbaum@xxxxxxxxxx, Orran Y Krieger <okrieg@xxxxxxxxxx>
Delivery-date: Wed, 08 Jun 2005 18:39:03 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D28212D@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

"Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx> wrote on 06/08/2005 02:25:56 PM:

> > The key point is that with
> > kernel-level preemption notification, VCPUs are always in
> > kernel mode when suspended, never in user mode.  Application
> > state is always saved in Linux, not in Xen, and is available
> > to be resumed on another VCPU if Linux so chooses.
> In principle, but...
> Do you believe this is going to interact well with Linux's work stealing
> CPU migration? I haven't looked closely at the current code, but from
> Linux's scheduler's POV the de-scheduled (yielded) CPU looks like a
> perfectly healthy CPU, so there's no particular reason that another CPU
> would steal work from it (without hacking the algorithm, which I suppose
> we could do). Also, do you have to do something special in your yield
> routine to ensure that no real process is currently running on the
> yielded processor so that all processes on the run queue are available
> for stealing?
> Ian

In our original posting, we proposed that the Linux interrupt handler for preemption notifications would create (or unblock) a high-priority kernel thread which would then yield back to the hypervisor.  To Linux on other CPUs, the de-scheduled CPU would appear to be busy running the high-priority thread, and all real work that that CPU had been doing would be eligible for stealing.

I don't think that Ryan has yet implemented the high-priority thread part of the proposal, but that's always been part of the plan.

- Bryan
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>