Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1

[Scott Wood]

On Thu, Nov 04, 2004 at 08:44:16PM +0100, Ingo Molnar wrote:
> 
> * john cooper <john.cooper@xxxxxxxxxxx> wrote:
> > 
> > This is a fairly gnarly problem to address.  The obvious solution is
> > to hold spinlocks in the mutexes as the dependency tree is atomically
> > traversed.  However this will deadlock under MP due to the
> > unpredictable order of mutexes traversed.  If the dependency chain is
> > not traversed (and semantics applied) atomically, races exist which
> > cause promotion decisions to be made on [now] stale data.
> 
> is the order of locks in the dependency chain really unpredictable? If
> two chain walkers get two locks in opposite order, doesnt that mean that
> the lock ordering (as attempted by the blocked tasks) is deadlock-prone
> already? I.e. this scenario should not happen.

It *shouldn't*, but bugs do happen, and it'd be nice if a mutex
deadlock didn't get promoted into a less debuggable spinlock
deadlock.  Plus, if there's any intention of ever exporting this
priority inheritance mechanism to userspace locks, we don't want to
promote a userspace deadlock into a kernel one.

Given how rarely contention should occur, I don't think that a single
lock would be a bottleneck except for obscenely large SMP machines.

-Scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/