Re: [Xen-devel] scheduler independent forced vcpu selection

[Ryan Harper <ryanh@xxxxxxxxxx>]

* Stephan Diestelhorst <sd386@xxxxxxxxxxxx> [2005-05-19 09:04]:
> Ryan Harper schrieb:
> > * Stephan Diestelhorst <sd386@xxxxxxxxxxxx> [2005-05-18 09:04]:
> > 
> >>>I'm working on a new hypercall, do_confer, which allows the directed
> >>>yielding of a vcpu to another vcpu.  It is mainly used when a vcpu fails
> >>>to acquire a spinlock, yielding to the lock holder instead of spinning. I
> >>>ported the ppc64 spinlock implementation for the i386 linux portion.  In
> >>>implementing the hypercall, I've been trying to figure out how to get
> >>>the scheduler (I've only played with bvt) to run the vcpu passed in the
> >>>hypercall (after some validation) but I've run into various bad state
> >>>situations (do_softirq pending != 0 assert, '!active_ac_timer(timer)'
> >>>failed , and __task_on_runqueue(prev) failed) which tells me I
> >>>don't fully understand all of the book-keeping that is needed.  Has
> >>>anyone thought about how to do this with either BVT or the new EDF
> >>>scheduler?
> > 
> > 
> > After some thought, domain_wake(), followed by
> > raise_softirq(SCHEDULE_SOFTIRQ) does what I want and removes the huge
> > mess I was making in __enter_scheduler().  
> 
> Are you waking up the domain that holds the lock? Then you would rely on

Yes, that is the idea.

> the scheduler to give the woken domain a high "priority" (whatever this
> means for the current scheduler) and should start that domain
> immediatelly, right?

Yes, that is part of what is required.  I need to do two things after
validation of do_confer:

1) Wake the lock-holder vcpu
2) Schedule the lock-holder to only run for the remaining time-slice of
the current running vcpu.

Using domain_wake() and softirq, I'm only getting (1), but I have no
guarantee when the lock-holder is actually woken up.  

Any thoughts on how to get (2)?

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel