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

From: Scott Wood (scott_at_timesys.com)
Date: 11/05/04

  • Next message: Greg KH: "Re: [PATCH] 2.6 lm85.c driver update" 
    Date:	Fri, 5 Nov 2004 16:42:38 -0500
To: Ingo Molnar <mingo@elte.hu>

    On Thu, Nov 04, 2004 at 08:44:16PM +0100, Ingo Molnar wrote:
    >
    > * john cooper <john.cooper@timesys.com> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Greg KH: "Re: [PATCH] 2.6 lm85.c driver update"

    Relevant Pages

    • Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
      ... > to hold spinlocks in the mutexes as the dependency tree is atomically ... > unpredictable order of mutexes traversed. ... is the order of locks in the dependency chain really unpredictable? ...
      (Linux-Kernel)
    • Re: Recursion bug in -rt
      ... >> the theory that the locks themselves would not deadlock. ... As I said, if you don't want futex to deadlock the kernel, the ... >> the kernel deadlocks or not, because the deadlocking of the user app ...
      (Linux-Kernel)
    • Re: deadlock questions
      ... a deadlock victim is chosen and then ... locks until the transaction completes. ... Acquire row locks. ...
      (microsoft.public.sqlserver.server)
    • Re: Recursion bug in -rt
      ... this is to prevent a kernel hang due to application error. ... >> Can't you promote a user space futex deadlock into a kernel spin deadlock ... > the order of locks taken. ... When resolving the mutex chain (task A locks mutex 1 owned by B blocked ...
      (Linux-Kernel)
    • Re: Deadlock problem / tablock
      ... before the background job. ... getting exclusive table locks on the 4 tables it updates before doing any ... locks were acquired on tables a, c and d, but the job was waiting for table ... have no more information on what caused the deadlock, ...
      (microsoft.public.sqlserver.programming)