lkml.org 
[lkml]   [2004]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Priority Inheritance Test (Real-Time Preemption)
From
On Mon, Nov 22, 2004 at 01:37:41PM +0100, Ingo Molnar wrote:
> in the -RT patchset one of the reasons why i've gone for the completely
> preemptible variant is to trigger all priority inversion problems
> outright. In the first variant they didnt really trigger - but they were
> present. Once the locks were almost all preemptible, PI problems
> surfaced in a big way - causing people to report them and forcing me to
> fix them :-)
>
> There are lots of critical sections in Linux and we cannot design around
> them - so if the goal is hard-RT properties and latencies then priority
> inversion is a problem that has to be solved. Later on we could easily
> revert some of the hw-related spinlocks to raw spinlocks, and/or the
> known-O(1) critical sections as well.

Good. Yeah, the only piont I was making is not to cover up contention
problems, which are kernel performance problems with PI. That's all.

> the paper cited is not very persuasive to me though. It lists problems
> of an incomplete/incorrect PI implementation, and comes to the IMO false
> (and unrelated) conclusion that somehow PI-handling is not desired.

Yeah, I agree. PI has it's place, but the main point of the paper is
that getting a really good PI protocol is a very difficult thing and
might not be worth it if you can use other techniques. What you do with
that assertion is situational.

A number of those complaints, as I see it, don't apply to Linux because
of how it's avoided things like deadlocking, fine grainedness, etc... are
done. But he does, IMO, outline the difficulty of getting a decent PI
implementation.

> Obviously PI makes only sense if it's implemented correctly. I think i
> managed to fix the problems Esben's testsuite uncovered, in the current
> -RT patch. Anyway, this implementation is also special in that it relies
> on correct SMP locking of Linux:

I'll check it out.

> i dont have any intentions to turn Linux into a 'priority inheritance
> world'. PI handling is only a property of the PREEMPT_RT feature
> intended for the most latency-sensitive applications - the main and
> primary critical-section model of Linux is and should still be a healthy
> mix of spinlocks and mutexes. Having only mutexes (or only spinlocks) is
> an extreme that _does_ hurt the common case. PREEMPT_RT 'only' lives on
> the back of SMP-Linux.

Yeah, that's my point. The reason why/if/when Linux will be strong at RT
is because of the SMP work.

bill

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

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.426 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site