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: "Bryan S Rosenburg" <rosnbrg@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 8 Jun 2005 19:25:56 +0100
Cc: ryanh@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, hohnbaum@xxxxxxxxxx, Orran Y Krieger <okrieg@xxxxxxxxxx>
Delivery-date: Wed, 08 Jun 2005 18:25:07 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
Thread-index: AcVsPVefI/KnNGfSTzWYDZ2ScoDx1AABcaLw
Thread-topic: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding
> 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?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>