Message-ID: <41A1F4B2.10401@timesys.com>
Date: Mon, 22 Nov 2004 09:16:18 -0500
From: john cooper <john.cooper@timesys.com>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
MIME-Version: 1.0
To: "Bill Huey (hui)" <bhuey@lnxw.com>
CC: Esben Nielsen <simlo@phys.au.dk>, linux-kernel@vger.kernel.org,
       Ingo Molnar <mingo@elte.hu>, john cooper <john.cooper@timesys.com>
Subject: Re: Priority Inheritance Test (Real-Time Preemption)
References: <Pine.OSF.4.05.10411212107240.29110-100000@da410.ifa.au.dk> <20041122092302.GA7210@nietzsche.lynx.com>
In-Reply-To: <20041122092302.GA7210@nietzsche.lynx.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1741
Lines: 38

Bill Huey (hui) wrote:

> IMO, their needs to be statistical code in the mutex itself so that it can
> measure the frequency of PI events as well as depth of the inheritance
> chains and all data structure traversals. The problem with writing that
> stuff now is that there isn't proper priority propagation through the entire
> dependency chain in any mutex code that I've publically seen yet.> Patching
> this instrumentation in a mutex require a mutex with this built in
> functionality. IMO, PI should be considered a kind of contention overload
> condition and really a kind of fallback device to deal with these kind
> of exceptional circumstances.

I'd hazard a guess the reason existing implementations do not
do this type of dependency-chain closure is the complexity of a
general approach.  Getting correct behavior and scaling on SMP
require some restrictions of how lock ownership is maintained,
otherwise fine grained locking is not possible.  Another likely
reason is the fact more mechanism is getting put in place for
less likely inversion scenarios.  And when those scenarios do
exist the cost of effecting promotion closure may well be
greater than allowing the priority inversions to subside.
However this point of diminishing returns is application
dependent so there is no single, simple solution.

That said I don't see anything in the current work which precludes
doing any of the above.  To my eyes, the groundwork is already
in place.

-john


-- 
john.cooper@timesys.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/