public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: "Paul E. McKenney" <paulmck@us.ibm.com>
Cc: dipankar@in.ibm.com, shemminger@osdl.org, akpm@osdl.org,
	torvalds@osdl.org, rusty@au1.ibm.com, tgall@us.ibm.com,
	jim.houston@comcast.net, manfred@colorfullife.com, gh@us.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: Real-Time Preemption and RCU
Date: Fri, 18 Mar 2005 10:04:06 +0100	[thread overview]
Message-ID: <20050318090406.GA9188@elte.hu> (raw)
In-Reply-To: <20050318002026.GA2693@us.ibm.com>


* Paul E. McKenney <paulmck@us.ibm.com> wrote:

> 4. Preemptible read side.
> 
> 	RCU read-side critical sections can (in theory, anyway) be quite
> 	large, degrading realtime scheduling response.	Preemptible RCU
> 	read-side critical sections avoid such degradation.  Manual
> 	insertion of "preemption points" might be an alternative as well.
> 	But I have no intention of trying to settle the long-running
> 	argument between proponents of preemption and of preemption
> 	points.  Not today, anyway!  ;-)

i'm cleverly sidestepping that argument by offering 4 preemption models
in the -RT tree :-) We dont have to pick a winner, users will. The way
low latencies are achieved depends on the preemption model:

               ( ) No Forced Preemption (Server)
               ( ) Voluntary Kernel Preemption (Desktop)
               ( ) Preemptible Kernel (Low-Latency Desktop)
               (X) Complete Preemption (Real-Time)

"Server" is the current default !PREEMPT model. Best throughput, bad
worst-case latencies.

"Low-Latency Desktop" is the current PREEMPT model. Has some runtime
overhead relative to Server, offers fair worst-case latencies.

"Desktop" is a new mode that is somewhere between Server and Low-Latency
Desktop: it's what was initially called 'voluntary preemption'. It
doesnt make the kernel forcibly preemptible anywhere, but inserts a fair
number of preemption points to decrease latencies statistically, while
keeping the runtime overhead close to the "Server". (a variant of this
model is utilized by Fedora and RHEL4 currently, so if this gets
upstream i expect distros to pick it up - it can be a migration helper
towards the "Low-Latency Desktop" model.)

"Real-Time" is the no-compromises hard-RT model: almost everything but
the scheduler itself is fully preemptible. Phenomenal worst-case
latencies in every workload scenario, but also has the highest runtime
overhead.

preemptable RCU makes sense for the "Low-Latency Desktop" and
"Real-Time" preemption models - these are the ones that do forced
preemption.

	Ingo

  parent reply	other threads:[~2005-03-18  9:05 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-18  0:20 Real-Time Preemption and RCU Paul E. McKenney
2005-03-18  7:49 ` Ingo Molnar
2005-03-18 16:43   ` Paul E. McKenney
2005-03-18 17:11     ` Ingo Molnar
2005-03-18 17:29       ` Paul E. McKenney
2005-03-18 20:35       ` Paul E. McKenney
2005-03-18 22:22         ` Paul E. McKenney
2005-03-19  0:48           ` Paul E. McKenney
2005-03-18  8:44 ` Ingo Molnar
2005-03-18  9:04 ` Ingo Molnar [this message]
2005-03-18  9:38   ` Ingo Molnar
2005-03-18  9:13 ` Ingo Molnar
2005-03-18  9:28   ` Ingo Molnar
2005-03-18  9:53     ` Ingo Molnar
2005-03-18 15:33       ` Paul E. McKenney
2005-03-19  5:03     ` Manfred Spraul
2005-03-19 16:26       ` Ingo Molnar
2005-03-20  6:36         ` Manfred Spraul
2005-03-20  9:25           ` Thomas Gleixner
2005-03-20 16:57             ` Manfred Spraul
2005-03-20 21:38               ` Bill Huey
2005-03-20 21:59                 ` Bill Huey
2005-03-18 10:03 ` Ingo Molnar
2005-03-18 11:30   ` Ingo Molnar
2005-03-18 16:48     ` Esben Nielsen
2005-03-18 17:19       ` Ingo Molnar
2005-03-20 13:29         ` Esben Nielsen
2005-03-20 22:38           ` Paul E. McKenney
2005-03-20 23:23             ` Esben Nielsen
2005-03-22  5:53               ` Paul E. McKenney
2005-03-22  8:55                 ` Esben Nielsen
2005-03-22  9:20                   ` Ingo Molnar
2005-03-22 10:19                     ` Esben Nielsen
2005-03-23  5:40                   ` Paul E. McKenney
2005-03-23 11:44                     ` Esben Nielsen
2005-03-24  7:02                       ` Paul E. McKenney
2005-03-22 10:56           ` Ingo Molnar
2005-03-22 11:39             ` Esben Nielsen
2005-03-22 13:10               ` Ingo Molnar
2005-03-22 15:08                 ` Esben Nielsen
2005-03-18 15:48   ` Paul E. McKenney
2005-03-18 11:38 ` Ingo Molnar
2005-03-18 12:56 ` Bill Huey
2005-03-18 13:17   ` Bill Huey
2005-03-18 15:57     ` Paul E. McKenney
2005-03-18 16:02     ` Ingo Molnar
2005-03-18 16:55       ` Esben Nielsen
2005-03-22 10:04         ` Bill Huey
2005-03-22 10:17           ` Bill Huey
2005-03-22 10:34             ` Bill Huey
2005-03-22 10:38           ` Esben Nielsen
2005-03-18 22:26       ` Herbert Xu
2005-03-19 16:31         ` Ingo Molnar
2005-03-20  8:01           ` Kyle Moffett
2005-03-22  8:08             ` Ingo Molnar
2005-03-18 15:54   ` Paul E. McKenney
2005-03-18 15:58     ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2009-06-11 22:57 real-time preemption " James Huang

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=20050318090406.GA9188@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=dipankar@in.ibm.com \
    --cc=gh@us.ibm.com \
    --cc=jim.houston@comcast.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=paulmck@us.ibm.com \
    --cc=rusty@au1.ibm.com \
    --cc=shemminger@osdl.org \
    --cc=tgall@us.ibm.com \
    --cc=torvalds@osdl.org \
    /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