Messages in this thread | | | Date | Tue, 19 Aug 2008 04:40:13 -0400 | From | Gregory Haskins <> | Subject | Re: [PATCH RT RFC v4 1/8] add generalized priority-inheritance interface |
| |
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
[unhandled content-type:application/pgp-signature] | |