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

[Orran Y Krieger <okrieg@xxxxxxxxxx>]

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