* Esben Nielsen <[email protected]> wrote:
> > how do you guarantee that some other CPU doesnt send us on some
> > goose-chase?
>
> How should another CPU suddenly be able to insert stuff into a lock
> chain? Only the tasks themselves can do that and they are blocked on
> some lock - at least when we tested in some previous iteration.
> Ofcourse, they can have been signalled or timed out since, such they
> are already unblocked when the deadlock is reported. But that is not
> an error since the locks at some point actually were in a deadlock
> situation.
we are observing a non-time-coherent snapshot of the locking graph.
There is no guarantee that due to timeouts or signals the chain we
observe isnt artificially long - while if a time-coherent snapshot is
taken it is always fine. E.g. lets take dentry locks as an example:
their locking is ordered by the dentry (kernel-pointer) address. We
could in theory have a 'chain' of subsequent locking dependencies
related to 10,000 dentries, which are nicely ordered and create a
10,000-entry 'chain' if looked at in a non-time-coherent form. I.e. your
code could detect a deadlock where there's none. The more CPUs there
are, the larger the likelyhood is that other CPUs 'lure us' into a long
chain.
In other words: without taking all the locks we have no mathematical
proof that we detected a deadlock!
also, how does the taking of 2 locks only improve latencies? We still
have to hold the ->waiter_lock of this lock during this act, dont we? Or
can we do boosting with totally unlocked (and interrupts-enabled)
rescheduling points? If yes then the same situation could happen on UP
too: if there's lots of rescheduling of this boosting chain.
nevertheless it _might_ work in practice, and it's certainly elegant and
thus tempting. Could you try to port your patch to -rt10? [you can skip
most of the conflicting rt7->rt10 deltas in rtmutex.c i think.]
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
