public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Bill Huey <bhuey@lnxw.com>
Cc: Esben Nielsen <simlo@phys.au.dk>, linux-kernel@vger.kernel.org
Subject: Re: Priority Inheritance Test (Real-Time Preemption)
Date: Mon, 22 Nov 2004 13:37:41 +0100	[thread overview]
Message-ID: <20041122123741.GA13574@elte.hu> (raw)
In-Reply-To: <20041122092302.GA7210@nietzsche.lynx.com>


* Bill Huey <bhuey@lnxw.com> wrote:

> [...] There might be places where, if algorithmically bounded somehow,
> reverting some of the heavy hammered sleeping locks back to spinlocks
> would make the system faster and more controlled. rtc_lock possibly
> could be one of those places and other places that are as heavily as
> used as that.

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.

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.
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:

> Turning this into a "priority inheritance world" is just going to turn
> this project into the FreeBSD SMP project [...]

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.

	Ingo

  reply	other threads:[~2004-11-22 11:38 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-21 20:29 Priority Inheritance Test (Real-Time Preemption) Esben Nielsen
2004-11-22  0:27 ` Ingo Molnar
2004-11-23 13:34   ` Ingo Molnar
2004-11-23 15:47     ` Esben Nielsen
2004-11-23 23:03     ` Esben Nielsen
2004-11-24  3:42       ` Ingo Molnar
2004-11-24  7:51         ` Ingo Molnar
2004-11-24  8:07       ` Ingo Molnar
2004-11-24  8:33         ` Esben Nielsen
2004-11-24  9:55           ` Ingo Molnar
2004-11-24 10:18       ` Ingo Molnar
2004-11-25 15:46         ` Esben Nielsen
2004-11-25 16:58           ` Ingo Molnar
2004-11-25 16:08             ` Esben Nielsen
2004-11-25 17:14               ` Ingo Molnar
2004-11-25 22:08             ` Esben Nielsen
2004-11-26  1:08               ` Ingo Molnar
2004-11-26  0:34                 ` Ingo Molnar
2004-11-26  0:37                   ` Ingo Molnar
2004-11-26  8:52                     ` Esben Nielsen
2004-11-26 16:26                 ` Esben Nielsen
2004-11-26 20:41                   ` Ingo Molnar
2004-11-26 21:05                     ` Ingo Molnar
2004-11-27 23:05                       ` Esben Nielsen
2004-11-28  8:42                         ` Ingo Molnar
2004-11-28 15:55                           ` Esben Nielsen
2004-11-29  9:59                             ` Ingo Molnar
2004-11-29 15:07                               ` Esben Nielsen
2004-11-29 15:56                                 ` Ingo Molnar
2004-11-29 15:57                                   ` Ingo Molnar
2004-11-29 16:50                                     ` Esben Nielsen
2004-11-30  8:49                                       ` Ingo Molnar
2004-11-22  9:23 ` Bill Huey
2004-11-22 12:37   ` Ingo Molnar [this message]
2004-11-22 21:25     ` Bill Huey
2004-11-22 14:16   ` john cooper
2004-11-22 15:24     ` Ingo Molnar
2004-11-23  1:19       ` john cooper
2004-11-23  8:13         ` Esben Nielsen
2004-11-23  9:21         ` Ingo Molnar
2004-11-22 21:30     ` Bill Huey
2004-11-23  1:34       ` john cooper
2004-11-22 16:12   ` Esben Nielsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041122123741.GA13574@elte.hu \
    --to=mingo@elte.hu \
    --cc=bhuey@lnxw.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simlo@phys.au.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox