Re: [PATCH] Abstracted Priority Inheritance for RT

[john cooper]

Perez-Gonzalez, Inaky wrote:
> It doesn't matter in which space the tasks are, a deadlock 
> condition can happen anywhere and that can easily lead to 
> infinite recursion/iteration (as bad). I seem to remember Ingo
> mentioning he had taken care of full transitivity (or maybe it
> was somebody else saying it).

That might have been me.  The last time I looked at this
specifically, full transitive promotion was being done in
the RT patch.  However unlike your attempt at scaling the
lock scope, the RT patch had one lock which coordinated
all mutex dependency traversals system wide.  This lock
must be speculatively acquired even before we ascertain
transitive promotion is required.

So it doesn't scale as well as it could in the case of
large count SMP systems.  The response was that of "get
it to work first and then we'll get it to scale" which
is reasonable.

When I looked at this sometime in the latter part of last
year I was concerned there was an inherent hierarchy violation
possible in the kernel for the case of fine grained (per-mutex)
locking when doing a transitive promotion traversal.   The
order of traversal is dependent upon the application's lock
acquisition sequence.  Ingo pointed out there shouldn't be a
kernel hierarchy inversion if it was first determined the
application itself wasn't violating it's own lock acquisition
hierarchy.  I recall this to be a valid and simplifying
assumption at the time though I haven't had cause to
follow up on the issue since then.

-john



--
john.cooper@xxxxxxxxxxx
-
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/