Re: [PATCH RT RFC v4 1/8] add generalized priority-inheritance interface

From: Gregory Haskins
Date: Tue Aug 19 2008 - 04:42:44 EST


Hi Peter,

Peter Zijlstra wrote:
On Fri, 2008-08-15 at 16:28 -0400, Gregory Haskins wrote:
The kernel currently addresses priority-inversion through priority-
inheritence. However, all of the priority-inheritence logic is
integrated into the Real-Time Mutex infrastructure. This causes a few
problems:

1) This tightly coupled relationship makes it difficult to extend to
other areas of the kernel (for instance, pi-aware wait-queues may
be desirable).
2) Enhancing the rtmutex infrastructure becomes challenging because
there is no seperation between the locking code, and the pi-code.

This patch aims to rectify these shortcomings by designing a stand-alone
pi framework which can then be used to replace the rtmutex-specific
version. The goal of this framework is to provide similar functionality
to the existing subsystem, but with sole focus on PI and the
relationships between objects that can boost priority, and the objects
that get boosted.

We introduce the concept of a "pi_source" and a "pi_sink", where, as the
name suggests provides the basic relationship of a priority source, and
its boosted target. A pi_source acts as a reference to some arbitrary
source of priority, and a pi_sink can be boosted (or deboosted) by
a pi_source. For more details, please read the library documentation.

There are currently no users of this inteface.

You should have started out by discussing your design - the document
just rambles a bit about some implementation details - it doesn't talk
about how it maps to the PI problem space.

The doc is still a work-in-progress, but point taken ;) I will address this shortly.


Anyway - from what I can make of the code, you managed to convert the pi
graph walking code that used to be in rt_mutex_adjust_prio_chain() and
was iterative, into a recursive function call.

Not something you should do lightly..

As we discussed on IRC yesterday, you are correct here. I was thinking that the graph couldn't get deeper than a few dozen entries, but I forgot about userspace futex access. But, this is precisely what the "release early" policy is designed to catch ;)

I think I can make a slight adjustment to the model to return it to an iterative design. I will address this in v5.

Thanks for the review, Peter!

Regards,
-Greg




Attachment: signature.asc
Description: OpenPGP digital signature