Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@osdl.org> wrote:

> I really can't think of any blocking kernel lock where priority 
> inheritance would make _any_ sense at all. Please give me an example.

you are completely right, most of the blocking kernel locks we have in 
Linux are an extremely poor candidate for priority inheritance. Most of 
them are totally noncritical, or cover so long codepaths that 'latency 
guarantees' and 'priority inheritance' make little sense for them.

the reason why we still have transformed most of the stock semaphore 
users to generic mutexes in the -rt kernel is mostly because i wanted to 
have _one_ central lock implementation. Firstly, it makes alot of sense 
to consolidate code on embedded platforms anyway. Secondly, it was much 
easier to implement (and validate) one robust locking primitive, than to 
implement 5 separate primitives. The fact that this also made semaphores 
PI-able is just a side-effect, with little to no practical relevance.

maybe ->i_sem is one notable exception: it is often held in critical 
codepaths, and it's really hard for even the most-well-controlled RT app 
to achieve _total_ isolation from the 'unprivileged' filesystem space.  
So occasional 'resource sharing' in form of hitting an i_sem of another 
task may still occur, and PI can at least reduce the worst-case cost 
somehow. (even though i_sem codepaths are by no means deterministic!)

so in the -rt kernel, every semaphore, rw-semaphore, spinlock, rwlock 
and seqlock [and in the latest -rt patches, every futex too] is 
abstracted off a central generic mutex type, which mutex is blocking and 
supports priority queueing and priority inheritance. It also has an 
extensive debugging framework, which we didnt want to duplicate for 
every separate lock object.

we also have a facility in the -rt kernel that traces the worst-case 
latency path of critical applications (the 'latency tracer'), when mixed 
with non-critical workloads, so we have quite good experience about what 
kind of locks make a difference and what kind of locks make no 
difference.

we also definitely know that priority inheritance done over _all_ these 
lock objects makes a very real quality difference in practice, resulting 
in real-time apps experiencing much lower worst-case latencies than 
under the stock kernel. It is true that you could live without priority 
inheritance, in cases were the RT app can be rewritten to have totally 
separated resources, but in practice that is only possible for the 
simplest applications.

	Ingo
-
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/