Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Ingo Molnar <mingo@xxxxxxx>
- Date: Mon, 19 Dec 2005 17:08:54 +0100
* Linus Torvalds <torvalds@xxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Thomas Gleixner
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Linus Torvalds
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Thomas Gleixner
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Linus Torvalds
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Thomas Gleixner
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Linus Torvalds
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Joe Korty
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Steven Rostedt
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Linus Torvalds
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- Prev by Date: selfmade serial driver problem with chipset other than VIA
- Next by Date: disk problem
- Previous by thread: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- Next by thread: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- Index(es):
Relevant Pages
|
