All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.