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

* 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.

Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253

Xen-devel mailing list