[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48AA86ED.4060407@novell.com>
Date: Tue, 19 Aug 2008 04:40:13 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: mingo@...e.hu, paulmck@...ux.vnet.ibm.com, tglx@...utronix.de,
rostedt@...dmis.org, linux-kernel@...r.kernel.org,
linux-rt-users@...r.kernel.org, gregory.haskins@...il.com,
David.Holmes@....com, jkacur@...il.com
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
Download attachment "signature.asc" of type "application/pgp-signature" (258 bytes)
Powered by blists - more mailing lists