Re: PI patch against 2.6.16-rt9

[Ingo Molnar <mingo@elte.hu>]

* 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