lkml.org 
[lkml]   [2006]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PI patch against 2.6.16-rt9

* Esben Nielsen <simlo@phys.au.dk> 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 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/

\
 
 \ /
  Last update: 2006-03-27 02:26    [W:0.084 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site