RE: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding
"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
> perfectly healthy CPU, so there's no particular reason that another
> 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?
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.
Xen-devel mailing list