Re: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding
* Bryan Rosenburg <rosnbrg@xxxxxxxxxx> [2005-06-08 13:40]:
> "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.
That is correct. I attempted to schedule some work on a particular cpu
in the interrupt handler but I couldn't quite get it working.
Currently, we are yielding in the interrupt handler which isn't what we
proposed, but I had hoped that it was close enough to see the general
effectiveness of the approach.
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
Xen-devel mailing list