<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/kernel/rcutree_plugin.h, branch v3.5</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v3.5</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v3.5'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2012-07-02T18:39:19Z</updated>
<entry>
<title>Revert "rcu: Move PREEMPT_RCU preemption to switch_to() invocation"</title>
<updated>2012-07-02T18:39:19Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paulmck@linux.vnet.ibm.com</email>
</author>
<published>2012-07-02T14:08:42Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=cba6d0d64ee53772b285d0c0c288deefbeaf7775'/>
<id>urn:sha1:cba6d0d64ee53772b285d0c0c288deefbeaf7775</id>
<content type='text'>
This reverts commit 616c310e83b872024271c915c1b9ab505b9efad9.
(Move PREEMPT_RCU preemption to switch_to() invocation).
Testing by Sasha Levin &lt;levinsasha928@gmail.com&gt; showed that this
can result in deadlock due to invoking the scheduler when one of
the runqueue locks is held.  Because this commit was simply a
performance optimization, revert it.

Reported-by: Sasha Levin &lt;levinsasha928@gmail.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Tested-by: Sasha Levin &lt;levinsasha928@gmail.com&gt;
</content>
</entry>
<entry>
<title>rcu: Precompute RCU_FAST_NO_HZ timer offsets</title>
<updated>2012-06-07T03:43:28Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paul.mckenney@linaro.org</email>
</author>
<published>2012-05-10T23:41:44Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=aa9b16306e3243229580ff889cc59fd66bf77973'/>
<id>urn:sha1:aa9b16306e3243229580ff889cc59fd66bf77973</id>
<content type='text'>
When a CPU is entering dyntick-idle mode, tick_nohz_stop_sched_tick()
calls rcu_needs_cpu() see if RCU needs that CPU, and, if not, computes the
next wakeup time based on the timer wheels.  Only later, when actually
entering the idle loop, rcu_prepare_for_idle() will be invoked.  In some
cases, rcu_prepare_for_idle() will post timers to wake the CPU back up.
But all for naught: The next wakeup time for the CPU has already been
computed, and posting a timer afterwards does not force that wakeup
time to be recomputed.  This means that rcu_prepare_for_idle()'s have
no effect.

This is not a problem on a busy system because something else will wake
up the CPU soon enough.  However, on lightly loaded systems, the CPU
might stay asleep for a considerable length of time.  If that CPU has
a callback that the rest of the system is waiting on, the system might
run very slowly or (in theory) even hang.

This commit avoids this problem by having rcu_needs_cpu() give
tick_nohz_stop_sched_tick() an estimate of when RCU will need the CPU
to wake back up, which tick_nohz_stop_sched_tick() takes into account
when programming the CPU's wakeup time.  An alternative approach is
for rcu_prepare_for_idle() to use hrtimers instead of normal timers,
but timers are much more efficient than are hrtimers for frequently
and repeatedly posting and cancelling a given timer, which is exactly
what RCU_FAST_NO_HZ does.

Reported-by: Pascal Chapperon &lt;pascal.chapperon@wanadoo.fr&gt;
Reported-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Paul E. McKenney &lt;paul.mckenney@linaro.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Tested-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Tested-by: Pascal Chapperon &lt;pascal.chapperon@wanadoo.fr&gt;
</content>
</entry>
<entry>
<title>rcu: Move RCU_FAST_NO_HZ per-CPU variables to rcu_dynticks structure</title>
<updated>2012-06-07T03:43:28Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paul.mckenney@linaro.org</email>
</author>
<published>2012-05-09T19:07:05Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5955f7eecd77d6b440db278b266cfecdb72ecd00'/>
<id>urn:sha1:5955f7eecd77d6b440db278b266cfecdb72ecd00</id>
<content type='text'>
The RCU_FAST_NO_HZ code relies on a number of per-CPU variables.
This works, but is hidden from someone scanning the data structures
in rcutree.h.  This commit therefore converts these per-CPU variables
to fields in the per-CPU rcu_dynticks structures.

Suggested-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Paul E. McKenney &lt;paul.mckenney@linaro.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Tested-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Tested-by: Pascal Chapperon &lt;pascal.chapperon@wanadoo.fr&gt;
</content>
</entry>
<entry>
<title>rcu: Update RCU_FAST_NO_HZ tracing for lazy callbacks</title>
<updated>2012-06-07T03:43:27Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paul.mckenney@linaro.org</email>
</author>
<published>2012-05-06T02:10:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=fd4b352687fd8604d49c190c4c9ea9e369fd42d5'/>
<id>urn:sha1:fd4b352687fd8604d49c190c4c9ea9e369fd42d5</id>
<content type='text'>
In the current code, a short dyntick-idle interval (where there is
at least one non-lazy callback on the CPU) and a long dyntick-idle
interval (where there are only lazy callbacks on the CPU) are traced
identically, which can be less than helpful.  This commit therefore
emits different event traces in these two cases.

Signed-off-by: Paul E. McKenney &lt;paul.mckenney@linaro.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Tested-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Tested-by: Pascal Chapperon &lt;pascal.chapperon@wanadoo.fr&gt;
</content>
</entry>
<entry>
<title>Merge branches 'barrier.2012.05.09a', 'fixes.2012.04.26a', 'inline.2012.05.02b' and 'srcu.2012.05.07b' into HEAD</title>
<updated>2012-05-11T17:14:21Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paulmck@linux.vnet.ibm.com</email>
</author>
<published>2012-05-11T17:14:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=dc36be4419311fd57becdf54bfeef6bd04a6741d'/>
<id>urn:sha1:dc36be4419311fd57becdf54bfeef6bd04a6741d</id>
<content type='text'>
barrier:  Reduce the amount of disturbance by rcu_barrier() to the rest of
    	the system.  This branch also includes improvements to
    	RCU_FAST_NO_HZ, which are included here due to conflicts.
fixes:  Miscellaneous fixes.
inline:  Remaining changes from an abortive attempt to inline
    	preemptible RCU's __rcu_read_lock().  These are (1) making
    	exit_rcu() avoid unnecessary work and (2) avoiding having
    	preemptible RCU record a blocked thread when the scheduler
    	declines to do a context switch.
srcu:	Lai Jiangshan's algorithmic implementation of SRCU, including
    	call_srcu().
</content>
</entry>
<entry>
<title>rcu: Explicitly initialize RCU_FAST_NO_HZ per-CPU variables</title>
<updated>2012-05-09T21:26:57Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paul.mckenney@linaro.org</email>
</author>
<published>2012-05-03T22:38:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=98248a0e24327bc64eb7518145c44bff7bebebc3'/>
<id>urn:sha1:98248a0e24327bc64eb7518145c44bff7bebebc3</id>
<content type='text'>
The current initialization of the RCU_FAST_NO_HZ per-CPU variables makes
needless and fragile assumptions about the initial value of things like
the jiffies counter.  This commit therefore explicitly initializes all of
them that are better started with a non-zero value.  It also adds some
comments describing the per-CPU state variables.

Signed-off-by: Paul E. McKenney &lt;paul.mckenney@linaro.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>rcu: Make RCU_FAST_NO_HZ handle timer migration</title>
<updated>2012-05-09T21:26:56Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paul.mckenney@linaro.org</email>
</author>
<published>2012-04-30T21:16:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=21e52e15666323078b8517a4312712579176b56f'/>
<id>urn:sha1:21e52e15666323078b8517a4312712579176b56f</id>
<content type='text'>
The current RCU_FAST_NO_HZ assumes that timers do not migrate unless a
CPU goes offline, in which case it assumes that the CPU will have to come
out of dyntick-idle mode (cancelling the timer) in order to go offline.
This is important because when RCU_FAST_NO_HZ permits a CPU to enter
dyntick-idle mode despite having RCU callbacks pending, it posts a timer
on that CPU to force a wakeup on that CPU.  This wakeup ensures that the
CPU will eventually handle the end of the grace period, including invoking
its RCU callbacks.

However, Pascal Chapperon's test setup shows that the timer handler
rcu_idle_gp_timer_func() really does get invoked in some cases.  This is
problematic because this can cause the CPU that entered dyntick-idle
mode despite still having RCU callbacks pending to remain in
dyntick-idle mode indefinitely, which means that its RCU callbacks might
never be invoked.  This situation can result in grace-period delays or
even system hangs, which matches Pascal's observations of slow boot-up
and shutdown (https://lkml.org/lkml/2012/4/5/142).  See also the bugzilla:

	https://bugzilla.redhat.com/show_bug.cgi?id=806548

This commit therefore causes the "should never be invoked" timer handler
rcu_idle_gp_timer_func() to use smp_call_function_single() to wake up
the CPU for which the timer was intended, allowing that CPU to invoke
its RCU callbacks in a timely manner.

Reported-by: Pascal Chapperon &lt;pascal.chapperon@wanadoo.fr&gt;
Signed-off-by: Paul E. McKenney &lt;paul.mckenney@linaro.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>rcu: Make exit_rcu() more precise and consolidate</title>
<updated>2012-05-02T21:48:27Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paul.mckenney@linaro.org</email>
</author>
<published>2012-04-13T19:54:22Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9dd8fb16c36178df2066387d2abd44d8b4dca8c8'/>
<id>urn:sha1:9dd8fb16c36178df2066387d2abd44d8b4dca8c8</id>
<content type='text'>
When running preemptible RCU, if a task exits in an RCU read-side
critical section having blocked within that same RCU read-side critical
section, the task must be removed from the list of tasks blocking a
grace period (perhaps the current grace period, perhaps the next grace
period, depending on timing).  The exit() path invokes exit_rcu() to
do this cleanup.

However, the current implementation of exit_rcu() needlessly does the
cleanup even if the task did not block within the current RCU read-side
critical section, which wastes time and needlessly increases the size
of the state space.  Fix this by only doing the cleanup if the current
task is actually on the list of tasks blocking some grace period.

While we are at it, consolidate the two identical exit_rcu() functions
into a single function.

Signed-off-by: Paul E. McKenney &lt;paul.mckenney@linaro.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Tested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;

Conflicts:

	kernel/rcupdate.c
</content>
</entry>
<entry>
<title>rcu: Move PREEMPT_RCU preemption to switch_to() invocation</title>
<updated>2012-05-02T21:43:23Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paul.mckenney@linaro.org</email>
</author>
<published>2012-03-27T23:02:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=616c310e83b872024271c915c1b9ab505b9efad9'/>
<id>urn:sha1:616c310e83b872024271c915c1b9ab505b9efad9</id>
<content type='text'>
Currently, PREEMPT_RCU readers are enqueued upon entry to the scheduler.
This is inefficient because enqueuing is required only if there is a
context switch, and entry to the scheduler does not guarantee a context
switch.

The commit therefore moves the enqueuing to immediately precede the
call to switch_to() from the scheduler.

Signed-off-by: Paul E. McKenney &lt;paul.mckenney@linaro.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Tested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>rcu: Ensure that RCU_FAST_NO_HZ timers expire on correct CPU</title>
<updated>2012-05-01T15:22:50Z</updated>
<author>
<name>Paul E. McKenney</name>
<email>paul.mckenney@linaro.org</email>
</author>
<published>2012-03-15T19:16:26Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f511fc624642f0bb8cf65aaa28979737514d4746'/>
<id>urn:sha1:f511fc624642f0bb8cf65aaa28979737514d4746</id>
<content type='text'>
Timers are subject to migration, which can lead to the following
system-hang scenario when CONFIG_RCU_FAST_NO_HZ=y:

1.	CPU 0 executes synchronize_rcu(), which posts an RCU callback.

2.	CPU 0 then goes idle.  It cannot immediately invoke the callback,
	but there is nothing RCU needs from ti, so it enters dyntick-idle
	mode after posting a timer.

3.	The timer gets migrated to CPU 1.

4.	CPU 0 never wakes up, so the synchronize_rcu() never returns, so
	the system hangs.

This commit fixes this problem by using mod_timer_pinned(), as suggested
by Peter Zijlstra, to ensure that the timer is actually posted on the
running CPU.

Reported-by: Dipankar Sarma &lt;dipankar@in.ibm.com&gt;
Signed-off-by: Paul E. McKenney &lt;paul.mckenney@linaro.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
</content>
</entry>
</feed>
