Re: [Xen-devel] Wait Queues

[Keir Fraser <keir@xxxxxxx>]

On 08/11/2012 15:39, "Andres Lagar-Cavilla" <andreslc@xxxxxxxxxxxxxx> wrote:

>> dom0 vcpu?.
> Uhmm. But it seems there is _some_ method to the madness. Luckily mm locks are
> all taken after the p2m lock (and enforced that way). dom0 can grab ... the
> big domain lock? the grant table lock?
> 
> Perhaps we can categorize locks between reflexive or foreign (not that we have
> abundant space in the spin lock struct to stash more flags) and perform some
> sort of enforcement like what goes on in the mm layer. Xen insults via
> BUG_ON's are a strong conditioning tool for developers. It is certainly
> simpler to tease out the locks that might deadlock dom0 than all possible
> locks, including RCU read-locks.
> 
> What I mean:
> 
> BUG_ON(current->domain != d && lock_is_reflexive)
> An example of a reflexive lock is the per page sharing lock.
> 
> BUG_ON(prepare_to_wait && current->domain->holds_foreign_lock)
> An example of a transitive lock is the gran table lock.
> 
> A third category would entail global locks like the domain list, which are
> identical to a foreign lock wrt to this analysis.
> 
> Another benefit of this is that only reflexive locks need to be made
> sleep-capable, not everything under the sun. I.e. the possibility of livelock
> is corralled to apply only to vcpus of the same domain, and then it's avoided
> by making those lock holders re-schedulable.

This sounds possible. RCU read locks will often count as global locks by the
way, as they are most often used as an alternative to taking a global
spinlock or multi-reader lock. So sleeping in RCU critical regions is
generally not going to be a good idea. Perhaps it will turn out that such
regions don't get in your way too often.

> Andres



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel