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

[Bryan S Rosenburg <rosnbrg@xxxxxxxxxx>]

"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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel