All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: ego@in.ibm.com, linux-kernel@vger.kernel.org,
	linux-rt-users@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Steven Rostedt <rostedt@goodmis.org>,
	Dipankar Sarma <dipankar@in.ibm.com>, Ted Tso <tytso@us.ibm.com>,
	dvhltc@us.ibm.com, Oleg Nesterov <oleg@tv-sign.ru>,
	Andrew Morton <akpm@linux-foundation.org>,
	bunk@kernel.org, Josh Triplett <josh@freedesktop.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC PATCH 4/6] Preempt-RCU: Implementation
Date: Sat, 1 Mar 2008 11:39:03 -0800	[thread overview]
Message-ID: <20080301193903.GC15887@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0802291330590.2723@scrub.home>

On Fri, Feb 29, 2008 at 01:38:15PM +0100, Roman Zippel wrote:
> Hi
> 
> On Thu, 28 Feb 2008, Paul E. McKenney wrote:
> 
> > > Why got this moved into init/Kconfig?
> > 
> > Because there are some arches that don't have kernel/Kconfig.preempt,
> > its earlier home.  Therefore, putting it into kernel/Kconfig.preempt
> > broke those arches' builds by supplying neither PREEMPT_RCU nor
> > CLASSIC_RCU.
> > 
> > > Now it's somewhere in the root menu, not really belonging to anything.
> > 
> > Do you have a suggested location?
> > 
> > > Also why is this a choice? Are more RCU types planned?
> > 
> > I don't expect additional drop-in replacements for RCU, though people
> > are certainly free to experiment if they wish.  It is a choice because
> > this gives people a very clear idea of the two options and because
> > it makes the implementation a bit cleaner.
> 
> I'd suggest to move PREEMPT_RCU back to Kconfig.preempt and if you really 
> need the second symbol leave this behind (maybe with a comment):
> 
> config CLASSIC_RCU
> 	def_bool !PREEMPT_RCU
> 
> Once there are more options, we can still look for a better place...
> 
> Also could you please add a proper dependency to RCU_TRACE on PREEMPT_RCU, 
> so that this condition isn't needed anymore:
> 
> ifeq ($(CONFIG_PREEMPT_RCU),y)
> obj-$(CONFIG_RCU_TRACE) += rcupreempt_trace.o
> endif

Is this what you had in mind?  I don't have any way to test on a
system not supporting CONFIG_PREEMPT, but seems to work on x86.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---

 init/Kconfig           |   34 +++-------------------------------
 kernel/Kconfig.preempt |   15 +++++++++++++++
 2 files changed, 18 insertions(+), 31 deletions(-)

diff -urpNa -X dontdiff linux-2.6.25-rc3/init/Kconfig linux-2.6.25-rc3-preempt_rcu/init/Kconfig
--- linux-2.6.25-rc3/init/Kconfig	2008-02-26 16:58:42.000000000 -0800
+++ linux-2.6.25-rc3-preempt_rcu/init/Kconfig	2008-03-01 11:30:59.000000000 -0800
@@ -860,38 +860,10 @@ source "block/Kconfig"
 config PREEMPT_NOTIFIERS
 	bool
 
-choice
-	prompt "RCU implementation type:"
-	default CLASSIC_RCU
-	help
-	  This allows you to choose either the classic RCU implementation
-	  that is designed for best read-side performance on non-realtime
-	  systems, or the preemptible RCU implementation for best latency
-	  on realtime systems.  Note that some kernel preemption modes
-	  will restrict your choice.
-
-	  Select the default if you are unsure.
-
 config CLASSIC_RCU
-	bool "Classic RCU"
+	def_bool !PREEMPT_RCU
 	help
 	  This option selects the classic RCU implementation that is
 	  designed for best read-side performance on non-realtime
-	  systems.
-
-	  Say Y if you are unsure.
-
-config PREEMPT_RCU
-	bool "Preemptible RCU"
-	depends on PREEMPT
-	help
-	  This option reduces the latency of the kernel by making certain
-	  RCU sections preemptible. Normally RCU code is non-preemptible, if
-	  this option is selected then read-only RCU sections become
-	  preemptible. This helps latency, but may expose bugs due to
-	  now-naive assumptions about each RCU read-side critical section
-	  remaining on a given CPU through its execution.
-
-	  Say N if you are unsure.
-
-endchoice
+	  systems.  Classic RCU is the default.  Note that the
+	  PREEMPT_RCU symbol is used to select/deselect this option.
diff -urpNa -X dontdiff linux-2.6.25-rc3/kernel/Kconfig.preempt linux-2.6.25-rc3-preempt_rcu/kernel/Kconfig.preempt
--- linux-2.6.25-rc3/kernel/Kconfig.preempt	2008-02-26 16:58:42.000000000 -0800
+++ linux-2.6.25-rc3-preempt_rcu/kernel/Kconfig.preempt	2008-03-01 11:35:39.000000000 -0800
@@ -52,8 +52,23 @@ config PREEMPT
 
 endchoice
 
+config PREEMPT_RCU
+	bool "Preemptible RCU"
+	depends on PREEMPT
+	default n
+	help
+	  This option reduces the latency of the kernel by making certain
+	  RCU sections preemptible. Normally RCU code is non-preemptible, if
+	  this option is selected then read-only RCU sections become
+	  preemptible. This helps latency, but may expose bugs due to
+	  now-naive assumptions about each RCU read-side critical section
+	  remaining on a given CPU through its execution.
+
+	  Say N if you are unsure.
+
 config RCU_TRACE
 	bool "Enable tracing for RCU - currently stats in debugfs"
+	depends on PREEMPT_RCU
 	select DEBUG_FS
 	default y
 	help

  parent reply	other threads:[~2008-03-01 19:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 17:03 [RFC PATCH 0/6] RCU: Preemptible-RCU Gautham R Shenoy
2007-12-13 17:14 ` [RFC PATCH 1/6] Preempt-RCU: Use softirq instead of tasklets for RCU Gautham R Shenoy
2007-12-13 17:15 ` [RFC PATCH 2/6] Preempt-RCU: Reorganize RCU code into rcuclassic.c and rcupdate.c Gautham R Shenoy
2007-12-14 14:51   ` Johannes Weiner
2007-12-14 16:12     ` Paul E. McKenney
2007-12-13 17:16 ` [RFC PATCH 3/6] Preempt-RCU: Fix rcu_barrier for preemptive environment Gautham R Shenoy
2007-12-13 17:16 ` [RFC PATCH 4/6] Preempt-RCU: Implementation Gautham R Shenoy
2007-12-13 17:16   ` Gautham R Shenoy
2008-02-29  4:34   ` Roman Zippel
2008-02-29  4:53     ` Paul E. McKenney
2008-02-29 12:38       ` Roman Zippel
2008-02-29 13:55         ` Steven Rostedt
2008-03-01 19:39         ` Paul E. McKenney [this message]
2008-03-01 21:07           ` Steven Rostedt
2008-03-02  3:09             ` Roman Zippel
2008-03-02  3:06           ` Roman Zippel
2008-03-03 18:55             ` Paul E. McKenney
2008-03-04 20:22               ` [PATCH] move PREEMPT_RCU config option back under PREEMPT Paul E. McKenney
2008-03-04 20:55                 ` Steven Rostedt
2008-03-05  0:58                   ` Paul E. McKenney
2008-03-05  2:06                     ` Roman Zippel
2008-03-05 19:00                       ` Paul E. McKenney
2008-03-04 20:49               ` [RFC PATCH 4/6] Preempt-RCU: Implementation Roman Zippel
2008-02-29 13:53     ` Steven Rostedt
2008-02-29 14:31       ` Roman Zippel
2007-12-13 17:17 ` [RFC PATCH 5/6] Preempt-RCU: CPU Hotplug handling Gautham R Shenoy
2007-12-13 17:18 ` [RFC PATCH 6/6] Preempt-RCU: Update RCU Documentation Gautham R Shenoy
2007-12-13 17:18   ` Gautham R Shenoy
2007-12-13 20:42   ` Ingo Molnar
2007-12-13 21:06     ` Gautham R Shenoy
2007-12-13 17:36 ` [RFC PATCH 0/6] RCU: Preemptible-RCU Steven Rostedt
2007-12-13 20:42   ` Ingo Molnar
2007-12-13 20:56     ` Steven Rostedt
2007-12-13 21:09   ` Gautham R Shenoy
2007-12-13 20:38 ` Ingo Molnar
2007-12-13 23:41   ` Paul E. McKenney

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=20080301193903.GC15887@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=dipankar@in.ibm.com \
    --cc=dvhltc@us.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=josh@freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tytso@us.ibm.com \
    --cc=zippel@linux-m68k.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 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.