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

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 06/03/2005 05:17:16 PM:

> > However, one of our concerns with confer/directed yielding is
> > that the lock holder vcpu doesn't know that it was given a
> > time-slice and that it should voluntarily yield giving other
> > vcpus get a chance at the lock.
> > With out such a mechanism, one can imagine that the lock
> > holder would continue on and possibly grab the lock yet again
> > before being preempted to which another vcpu will then yield,
> > etc.  We could add something in the vcpu_info array
> > indicating that it was given a slice and in
> > _raw_spin_unlock() check and call do_yield().  These spinlock
> > changes certainly affect the speed of the spinlocks in Linux
> > which is one of the reasons we wanted to avoid directed
> > yielding or any other  mechanism that required spinlock accounting.
> Spinlock accounting that doesn't involve lock'ed operations might be OK.

Ian, remember we are not just talking about the kernel, the preemption notification scheme also solves in a natural and OS agnostic way performance problems from application locking.  The cost of a extra upcall to the already running OS should, we believe, be negligable in normal operation and solves all the problems in a natural way.

> > I don't know if you had a chance to see my status on the
> > [2]preemption notification from about a month ago.  I'm going
> > to bring that patch up to current and re-run the tests to see
> > where things are again.  Please take a look at the original results.
> Thanks, I did look at the graphs at the time. As I recall, the
> notification mechanism was beginning to look somewhat expensive under
> high context switch loads induced by IO.

Yeah, we realize now that the experiment was bogus, not representative of anything real, since the ping experiment could: 1) stress the rate of interrupts higher than any realistic workload, and 2) did so little work in the server that it wasn't worth it to do any preemption avoidance/tolerance technique. Ryan is looking at a more realistic workload now.

> We'll have to see what the cost
> of using spinlock accounting is. If there are no locked operations wre
> might be OK.

You can only use spinlock accounting for dealing with locking issues in kernel (unless you are willing to change application level programs and libs).  If preemption notification overhead is not prohibitive, the fact that it solves the application problem as well as the kernel problem seems like a compelling advantage over spinlock accounting, doesn't it?
Xen-devel mailing list