Hello everyone, 
This patchset is an updated version of the preemptible RCU patchset that

Paul McKenney had posted it in September earlier this year that can be

found here --> http://lkml.org/lkml/2007/9/10/213
This patchset incorporates the review comments from Oleg Nesterov

and Steven Rostedt.
The testing report of the patchset is as follows:

====================================================================

Patch-stack:  	2.6.23-rc3 + cpu-hotplug patches from

		http://lkml.org/lkml/2007/11/15/239 + Preempt-RCU

		patches.

Test:		RCU-Torture running parallelly with CPU-Hotplug

		operations.

Duration:	24 hours.

Architectures:	x86,x86_64, ppc64.

====================================================================
Currently it is based against the latest linux-2.6-sched-devel.git
Awaiting your feedback!
Thanks and Regards

gautham.

--

Gautham R Shenoy

Linux Technology Center

IBM India.

"Freedom comes with a price tag of responsibility, which is still a bargain,

because Freedom is priceless!"

--

thanks Gautham, the patchset from you and Paul looks good to me and i've

applied it to sched-devel.git to get it tested and reviewed some more.
from the Nitpicking Police, there are a couple of minor style

problems/warnings with the code, you can see it via:
  scripts/checkpatch.pl --file kernel/rcu*.c
nothing serious - RCU is still one of the cleanest subsystems in the

kernel:
                                      errors   lines of code   errors/KLOC

kernel/rcuclassic.c                        0             575             0

kernel/rcupdate.c                          1             138           7.2

kernel/rcupreempt.c                        0             953             0

kernel/rcupreempt_trace.c                  0             330             0

kernel/rcutorture.c                        8             995           8.0
the eventual goal would be to match:
   scripts/checkpatch.pl --file kernel/sched*.[ch]
output ;-)
	Ingo

--

This one is the exception to checkpatch.pl's rule against "volatile".  ;-)
The volatile declaration is within the ACCESS_ONCE() macro that is used

within rcu_read_lock() and rcu_read_unlock() to force the compiler to

maintain ordering with respect to interrupt handler running only on that
We should be able to make some progress in that direction.  ;-)
							Thanx, Paul

--

Hi Gautham,
Thanks for posting this. I believe this is the same version of preempt RCU

as we have in the RT patch. It seems to be very stable. I ran the RT patch

version of the RCU Preempt (just the Preempt RCU patches without RT on

latest git) on a 64way box and the results seems just as good (if not

slightly better) than classic RCU!  I'll rerun this patch series on that

box and post the results.
From what I'm seening with this, is that it is ready for mainline. These

patches should probably go into -mm and be ready for 2.6.25.  If Andrew

wants to wait for my results, I'll run them tonight.
Thanks Gautham, Paul and Dipankar for all this great work!
-- Steve
--

Hi Steve, 
The version of synchronize_sched() that's implemented in this patchset

requires these CPU-Hotplug patches -->

http://lkml.org/lkml/2007/11/15/239.
This is the reason why I rebased it against linux-2.6-sched-devel.git
Thanks and Regards

gautham.

--

Gautham R Shenoy

Linux Technology Center

IBM India.

"Freedom comes with a price tag of responsibility, which is still a bargain,

because Freedom is priceless!"

--

Steve, if you went with a fine comb over the code and have done a

thorough review, could you send me your Reviewed-by line for this

patchset?
	Ingo

--

Sure thing. And here's the thread that contains a lot of my review (and I

had some with Paul on IRC).
http://lkml.org/lkml/2007/9/10/213
Reviewed-by: Steven Rostedt <srostedt@redhat.com>
--

Preempt-RCU: Update RCU Documentation.
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
This patch updates the RCU documentation to reflect preemptible RCU as

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

---
 Documentation/RCU/RTFP.txt    |  210 +++++++++++++++++++++++++++++++++++++++--

 Documentation/RCU/rcu.txt     |   19 +++-

 Documentation/RCU/torture.txt |   11 +-

 3 files changed, 221 insertions(+), 19 deletions(-)
diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt

index 6221464..39ad8f5 100644

--- a/Documentation/RCU/RTFP.txt

+++ b/Documentation/RCU/RTFP.txt

@@ -9,8 +9,8 @@ The first thing resembling RCU was published in 1980, when Kung and Lehman

 [Kung80] recommended use of a garbage collector to defer destruction

 of nodes in a parallel binary search tree in order to simplify its

 implementation.  This works well in environments that have garbage

-collectors, but current production garbage collectors incur significant

-read-side overhead.

+collectors, but most production garbage collectors incur significant

+overhead.
 In 1982, Manber and Ladner [Manber82,Manber84] recommended deferring

 destruction until all threads running at that time have terminated, again

@@ -99,16 +99,25 @@ locking, reduces contention, reduces memory latency for readers, and

 parallelizes pipeline stalls and memory latency for writers.  However,

 these techniques still impose significant read-side overhead in the

 form of memory barriers.  Researchers at Sun worked along similar lines

-in the same timeframe [HerlihyLM02,HerlihyLMS03].  These techniques

-can be thought of as inside-out reference counts, where the count is

-represented by the number of hazard pointers referencing a given data

-structure (rather than the more conventional counter field within the

-data structure itself).

+in the same timeframe [HerlihyLM02].  These techniques can be thought

+of as inside-out reference counts, where the count is...
[ message continues ]

Gautham, this patch is missing your SoB line - could you please send it?
	Ingo

--

Sorry about that. I do take responsibility of this patch too!
Thanks and Regards

gautham.
---->

Preempt-RCU: Update RCU Documentation.
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
This patch updates the RCU documentation to reflect preemptible RCU as

well as recent publications.
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>

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

---
 Documentation/RCU/RTFP.txt    |  210 +++++++++++++++++++++++++++++++++++++++--

 Documentation/RCU/rcu.txt     |   19 +++-

 Documentation/RCU/torture.txt |   11 +-

 3 files changed, 221 insertions(+), 19 deletions(-)
diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt

index 6221464..39ad8f5 100644

--- a/Documentation/RCU/RTFP.txt

+++ b/Documentation/RCU/RTFP.txt

@@ -9,8 +9,8 @@ The first thing resembling RCU was published in 1980, when Kung and Lehman

 [Kung80] recommended use of a garbage collector to defer destruction

 of nodes in a parallel binary search tree in order to simplify its

 implementation.  This works well in environments that have garbage

-collectors, but current production garbage collectors incur significant

-read-side overhead.

+collectors, but most production garbage collectors incur significant

+overhead.
 In 1982, Manber and Ladner [Manber82,Manber84] recommended deferring

 destruction until all threads running at that time have terminated, again

@@ -99,16 +99,25 @@ locking, reduces contention, reduces memory latency for readers, and

 parallelizes pipeline stalls and memory latency for writers.  However,

 these techniques still impose significant read-side overhead in the

 form of memory barriers.  Researchers at Sun worked along similar lines

-in the same timeframe [HerlihyLM02,HerlihyLMS03].  These techniques

-can be thought of as inside-out reference counts, where the count is

-represented by the number of hazard pointers referencing a given data

-structure (rather than the more conventional counter fie...
[ message continues ]

Preempt-RCU: Implementation
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
This patch implements a new version of RCU which allows its read-side

critical sections to be preempted. It uses a set of counter pairs

to keep track of the read-side critical sections and flips them

when all tasks exit read-side critical section. The details

of this implementation can be found in this paper -
	http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf
and the article-
	http://lwn.net/Articles/253651/
This patch was developed as a part of the -rt kernel development and

meant to provide better latencies when read-side critical sections of

RCU don't disable preemption.  As a consequence of keeping track of RCU

readers, the readers have a slight overhead (optimizations in the paper).

This implementation co-exists with the "classic" RCU implementations

and can be switched to at compiler.
Also includes RCU tracing summarized in debugfs.
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>

Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>

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

---
 include/linux/rcuclassic.h       |    3

 include/linux/rcupdate.h         |   11 -

 include/linux/rcupreempt.h       |   86 ++++

 include/linux/rcupreempt_trace.h |   99 +++++

 include/linux/sched.h            |    5

 kernel/Kconfig.preempt           |   38 ++

 kernel/Makefile                  |    7

 kernel/fork.c                    |    4

 kernel/rcuclassic.c              |    1

 kernel/rcupreempt.c              |  816 ++++++++++++++++++++++++++++++++++++++

 kernel/rcupreempt_trace.c        |  330 +++++++++++++++

 11 files changed, 1394 insertions(+), 6 deletions(-)
diff --git a/include/linux/rcuclassic.h b/include/linux/rcuclassic.h

index 2b8b045..4d66242 100644

--- a/include/linux/rcuclassic.h

+++ b/include/linux/rcuclassic.h

@@ -157,5 +157,8 @@ extern void __rcu_init(void);

 extern void rcu_check_callbacks(int cpu, int user);

 extern void...
[ message continues ]

Hi,
Why got this moved into init/Kconfig?

Now it's somewhere in the root menu, not really belonging to anything.

Also why is this a choice? Are more RCU types planned?
bye, Roman

--

Why shouldn't it be a choice? You can have CLASSIC_RCU or PREEMPT_RCU, one

or the other and not both. Sounds perfect for being a choice.
-- Steve
--

Hi,
With this logic almost every bool could be implemented via choice.

A simple bool perfectly gives you two choices too.
bye, Roman

--

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
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.
							Thanx, Paul

--

Hi
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
Thanks.
bye, Roman

--

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 ...
[ message continues ]

Hi,
"default n" isn't really necessary, it's already the default.
bye, Roman
--

Fair enough.  But something like 125 Kconfig files in 2.6.25-rc3 have

at least one "default n" in them, so is it worth getting rid of it?

Seems to me that the explicit "default n" has some substantial readability

advantages.
						Thanx, Paul

--

Hi,
The inverse would mean all the other configs have a readability

disadvantage.

In most cases they can be simply removed, only in form of 'def_bool n' it

makes somewhat sense.
bye, Roman

--

Hello!
The original preemptible-RCU patch put the choice between classic and

preemptible RCU into kernel/Kconfig.preempt, which resulted in build

failures on machines not supporting CONFIG_PREEMPT.  This choice was

therefore moved to init/Kconfig, which worked, but placed the choice

between classic and preemptible RCU at the top level, a very obtuse choice

indeed.  This patch changes from the Kconfig "choice" mechanism to a pair

of booleans, only one of which (CONFIG_PREEMPT_RCU) is user-visible,

and is located in kernel/Kconfig.preempt, where one would expect it

to be.  The other (CONFIG_CLASSIC_RCU) is in init/Kconfig so that it

is available to all architectures, hopefully avoiding build breakage.

Thanks to Roman Zippel for suggesting this approach.
I have tested this, but sadly do not have access to a machine that does

not support CONFIG_PREEMPT.  However, I did edit my config in an attempt

to simulate this situation.
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

 	  T...
[ message continues ]

One minor comment, but otherwise:
You can get rid of the "help" part since it isn't visible to users.
-- Steve
--

So how about if I replace it with comment lines (starting with "#",

not with "comment")?
						Thanx, Paul

--

Hi,
Actually xconfig can display this text, so using the help like this is

fine.
bye, Roman

--

Cool, I will stick with the "help" clause, then.
							Thanx, Paul

--

Actually Paul, you don't need to make this an "option". Simply the default

if PREEMPT_RCU is not selected. In otherwords, no prompt.
	config CLASSIC_RCU

	  bool

	  depends on !PREEMPT_RCU

	  default y
Then, have the PREEMPT_RCU defined down below (as you already did), and

have it be the only option. That is, you can have normal RCU or select

to have PREEMPT_RCU.
If the user selects PREEMPT_RCU, CLASSIC_RCU will be unselected.
--

Hi,
There is no prompt. :)

"def_bool !PREEMPT_RCU" does the same as this.
bye, Roman

--

Ah, OK, you are saying that we should only show the option for

PREEMPT_RCU? If selected, we use that and if not, we default to

CLASSIC_RCU.
I guess that can work.
--

Preempt-RCU: CPU Hotplug handling
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
This patch allows preemptible RCU to tolerate CPU-hotplug operations.

It accomplishes this by maintaining a local copy of a map of online

CPUs, which it accesses under its own lock.
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>

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

---
 kernel/rcupreempt.c |  147 +++++++++++++++++++++++++++++++++++++++++++++++++--

 1 files changed, 142 insertions(+), 5 deletions(-)
diff --git a/kernel/rcupreempt.c b/kernel/rcupreempt.c

index a5aabb1..987cfb7 100644

--- a/kernel/rcupreempt.c

+++ b/kernel/rcupreempt.c

@@ -147,6 +147,8 @@ static char *rcu_try_flip_state_names[] =

 	{ "idle", "waitack", "waitzero", "waitmb" };

 #endif /* #ifdef CONFIG_RCU_TRACE */
+static cpumask_t rcu_cpu_online_map __read_mostly = CPU_MASK_NONE;

+

 /*

  * Enum and per-CPU flag to determine when each CPU has seen

  * the most recent counter flip.

@@ -445,7 +447,7 @@ rcu_try_flip_idle(void)
 	/* Now ask each CPU for acknowledgement of the flip. */
-	for_each_possible_cpu(cpu)

+	for_each_cpu_mask(cpu, rcu_cpu_online_map)

 		per_cpu(rcu_flip_flag, cpu) = rcu_flipped;
 	return 1;

@@ -461,7 +463,7 @@ rcu_try_flip_waitack(void)

 	int cpu;
 	RCU_TRACE_ME(rcupreempt_trace_try_flip_a1);

-	for_each_possible_cpu(cpu)

+	for_each_cpu_mask(cpu, rcu_cpu_online_map)

 		if (per_cpu(rcu_flip_flag, cpu) != rcu_flip_seen) {

 			RCU_TRACE_ME(rcupreempt_trace_try_flip_ae1);

 			return 0;

@@ -492,7 +494,7 @@ rcu_try_flip_waitzero(void)

 	/* Check to see if the sum of the "last" counters is zero. */
 	RCU_TRACE_ME(rcupreempt_trace_try_flip_z1);

-	for_each_possible_cpu(cpu)

+	for_each_cpu_mask(cpu, rcu_cpu_online_map)

 		sum += RCU_DATA_CPU(cpu)->rcu_flipctr[lastidx];

 	if (sum != 0) {

 		RCU_TRACE_ME(rcupreempt_trace_try_flip_ze1);

@@ -507,7 +509,7 @@ rcu_try_flip_waitzero(void)

 	smp_mb();  /*  ^^^^^^^^^^^^ */
 	/* Call for a memory...
[ message continues ]

Preempt-RCU: Reorganize RCU code into rcuclassic.c and rcupdate.c
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
This patch re-organizes the RCU code to enable multiple implementations

of RCU. Users of RCU continues to include rcupdate.h and the

RCU interfaces remain the same. This is in preparation for

subsequently merging the preemptible RCU implementation.
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>

Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>

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

---
 include/linux/rcuclassic.h |  161 ++++++++++++

 include/linux/rcupdate.h   |  168 ++++---------

 kernel/Makefile            |    2

 kernel/rcuclassic.c        |  576 ++++++++++++++++++++++++++++++++++++++++++++

 kernel/rcupdate.c          |  575 ++------------------------------------------

 5 files changed, 812 insertions(+), 670 deletions(-)
diff --git a/include/linux/rcuclassic.h b/include/linux/rcuclassic.h

new file mode 100644

index 0000000..2b8b045

--- /dev/null

+++ b/include/linux/rcuclassic.h

@@ -0,0 +1,161 @@

+/*

+ * Read-Copy Update mechanism for mutual exclusion (classic version)

+ *

+ * This program is free software; you can redistribute it and/or modify

+ * it under the terms of the GNU General Public License as published by

+ * the Free Software Foundation; either version 2 of the License, or

+ * (at your option) any later version.

+ *

+ * This program is distributed in the hope that it will be useful,

+ * but WITHOUT ANY WARRANTY; without even the implied warranty of

+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

+ * GNU General Public License for more details.

+ *

+ * You should have received a copy of the GNU General Public License

+ * along with this program; if not, write to the Free Software

+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

+ *

+ * Copyright IBM Corporation, 2001

+ *

+ * Author: Dipankar Sarma <dipankar@in.ibm.com>

+ *

+ * B...
[ message continues ]

Hi,
Those two functions are identical beside the difference of `rcu_data'

<-> `rcu_bh_data' and `rcu_ctrlblk' <-> `rcu_bh_ctrlblk'.
Is there a way to collapse the code into one helper function or would

that effect performance too much?
	Hannes

--

This code is performance critical, but on the other hand, perhaps gcc

has gotten smarter in the years since this was written.  (This patch is

just moving this code from one file to another, rather than writing it

from scratch.)  Would current gcc implementations be able to do the

inlining required?
							Thanx, Paul

--

Preempt-RCU: Fix rcu_barrier for preemptive environment.
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Fix rcu_barrier() to work properly in preemptive kernel environment.

Also, the ordering of callback must be preserved while moving

callbacks to another CPU during CPU hotplug.
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>

Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>

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

---
 kernel/rcuclassic.c |    2 +-

 kernel/rcupdate.c   |   10 ++++++++++

 2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/kernel/rcuclassic.c b/kernel/rcuclassic.c

index 11c16aa..deb2acc 100644

--- a/kernel/rcuclassic.c

+++ b/kernel/rcuclassic.c

@@ -371,9 +371,9 @@ static void __rcu_offline_cpu(struct rcu_data *this_rdp,

 	if (rcp->cur != rcp->completed)

 		cpu_quiet(rdp->cpu, rcp);

 	spin_unlock_bh(&rcp->lock);

+	rcu_move_batch(this_rdp, rdp->donelist, rdp->donetail);

 	rcu_move_batch(this_rdp, rdp->curlist, rdp->curtail);

 	rcu_move_batch(this_rdp, rdp->nxtlist, rdp->nxttail);

-	rcu_move_batch(this_rdp, rdp->donelist, rdp->donetail);

 }
 static void rcu_offline_cpu(int cpu)

diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c

index 0ccd009..760dfc2 100644

--- a/kernel/rcupdate.c

+++ b/kernel/rcupdate.c

@@ -115,7 +115,17 @@ void rcu_barrier(void)

 	mutex_lock(&rcu_barrier_mutex);

 	init_completion(&rcu_barrier_completion);

 	atomic_set(&rcu_barrier_cpu_count, 0);

+	/*

+	 * The queueing of callbacks in all CPUs must be atomic with

+	 * respect to RCU, otherwise one CPU may queue a callback,

+	 * wait for a grace period, decrement barrier count and call

+	 * complete(), while other CPUs have not yet queued anything.

+	 * So, we need to make sure that grace periods cannot complete

+	 * until all the callbacks are queued.

+	 */

+	rcu_read_lock();

 	on_each_cpu(rcu_barrier_func, NULL, 0, 1);

+	rcu_read_unlock();

 	wait_for_completion...
[ message continues ]

Preempt-RCU: Use softirq instead of tasklets for RCU
From: Dipankar Sarma <dipankar@in.ibm.com>
This patch makes RCU use softirq instead of tasklets.
It also adds a memory barrier after raising the softirq

inorder to ensure that the cpu sees the most recently updated

value of rcu->cur while processing callbacks.

The discussion of the related theoretical race pointed out

by James Huang can be found here --> http://lkml.org/lkml/2007/11/20/603
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>

---
 include/linux/interrupt.h |    1 +

 kernel/rcupdate.c         |   25 +++++++++++++++++--------

 2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h

index 2306920..c3db4a0 100644

--- a/include/linux/interrupt.h

+++ b/include/linux/interrupt.h

@@ -256,6 +256,7 @@ enum

 #ifdef CONFIG_HIGH_RES_TIMERS

 	HRTIMER_SOFTIRQ,

 #endif

+	RCU_SOFTIRQ, 	/* Preferable RCU should always be the last softirq */

 };
 /* softirq mask and active fields moved to irq_cpustat_t in

diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c

index a66d4d1..8658948 100644

--- a/kernel/rcupdate.c

+++ b/kernel/rcupdate.c

@@ -73,8 +73,6 @@ static struct rcu_ctrlblk rcu_bh_ctrlblk = {

 DEFINE_PER_CPU(struct rcu_data, rcu_data) = { 0L };

 DEFINE_PER_CPU(struct rcu_data, rcu_bh_data) = { 0L };
-/* Fake initialization required by compiler */

-static DEFINE_PER_CPU(struct tasklet_struct, rcu_tasklet) = {NULL};

 static int blimit = 10;

 static int qhimark = 10000;

 static int qlowmark = 100;

@@ -231,6 +229,18 @@ void rcu_barrier(void)

 }

 EXPORT_SYMBOL_GPL(rcu_barrier);
+/* Raises the softirq for processing rcu_callbacks. */

+static inline void raise_rcu_softirq(void)

+{

+	raise_softirq(RCU_SOFTIRQ);

+	/*

+	 * The smp_mb() here is required to ensure that this cpu's

+	 * __rcu_process_callbacks() reads the ...
[ message continues ]