2008-01-25 13:08:24 -07:00
|
|
|
/*
|
|
|
|
* Read-Copy Update mechanism for mutual exclusion
|
|
|
|
*
|
|
|
|
* 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
|
|
|
|
*
|
|
|
|
* Authors: Dipankar Sarma <dipankar@in.ibm.com>
|
|
|
|
* Manfred Spraul <manfred@colorfullife.com>
|
|
|
|
*
|
|
|
|
* Based on the original work by Paul McKenney <paulmck@us.ibm.com>
|
|
|
|
* and inputs from Rusty Russell, Andrea Arcangeli and Andi Kleen.
|
|
|
|
* Papers:
|
|
|
|
* http://www.rdrop.com/users/paulmck/paper/rclockpdcsproof.pdf
|
|
|
|
* http://lse.sourceforge.net/locking/rclock_OLS.2001.05.01c.sc.pdf (OLS2001)
|
|
|
|
*
|
|
|
|
* For detailed explanation of Read-Copy Update mechanism see -
|
|
|
|
* Documentation/RCU
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/rcupdate.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <asm/atomic.h>
|
|
|
|
#include <linux/bitops.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/completion.h>
|
|
|
|
#include <linux/moduleparam.h>
|
|
|
|
#include <linux/percpu.h>
|
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/cpu.h>
|
|
|
|
#include <linux/mutex.h>
|
2008-08-10 19:35:38 -06:00
|
|
|
#include <linux/time.h>
|
2008-01-25 13:08:24 -07:00
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
static struct lock_class_key rcu_lock_key;
|
|
|
|
struct lockdep_map rcu_lock_map =
|
|
|
|
STATIC_LOCKDEP_MAP_INIT("rcu_read_lock", &rcu_lock_key);
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_lock_map);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
/* Definition for rcupdate control block. */
|
|
|
|
static struct rcu_ctrlblk rcu_ctrlblk = {
|
|
|
|
.cur = -300,
|
|
|
|
.completed = -300,
|
2008-07-06 03:23:55 -06:00
|
|
|
.pending = -300,
|
2008-01-25 13:08:24 -07:00
|
|
|
.lock = __SPIN_LOCK_UNLOCKED(&rcu_ctrlblk.lock),
|
|
|
|
.cpumask = CPU_MASK_NONE,
|
|
|
|
};
|
|
|
|
static struct rcu_ctrlblk rcu_bh_ctrlblk = {
|
|
|
|
.cur = -300,
|
|
|
|
.completed = -300,
|
2008-07-06 03:23:55 -06:00
|
|
|
.pending = -300,
|
2008-01-25 13:08:24 -07:00
|
|
|
.lock = __SPIN_LOCK_UNLOCKED(&rcu_bh_ctrlblk.lock),
|
|
|
|
.cpumask = CPU_MASK_NONE,
|
|
|
|
};
|
|
|
|
|
|
|
|
DEFINE_PER_CPU(struct rcu_data, rcu_data) = { 0L };
|
|
|
|
DEFINE_PER_CPU(struct rcu_data, rcu_bh_data) = { 0L };
|
|
|
|
|
|
|
|
static int blimit = 10;
|
|
|
|
static int qhimark = 10000;
|
|
|
|
static int qlowmark = 100;
|
|
|
|
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
static void force_quiescent_state(struct rcu_data *rdp,
|
|
|
|
struct rcu_ctrlblk *rcp)
|
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
cpumask_t cpumask;
|
|
|
|
set_need_resched();
|
2008-08-05 10:21:44 -06:00
|
|
|
spin_lock(&rcp->lock);
|
2008-01-25 13:08:24 -07:00
|
|
|
if (unlikely(!rcp->signaled)) {
|
|
|
|
rcp->signaled = 1;
|
|
|
|
/*
|
|
|
|
* Don't send IPI to itself. With irqs disabled,
|
|
|
|
* rdp->cpu is the current cpu.
|
rcu: fix hotplug vs rcu race
Dhaval Giani reported this warning during cpu hotplug stress-tests:
| On running kernel compiles in parallel with cpu hotplug:
|
| WARNING: at arch/x86/kernel/smp.c:118
| native_smp_send_reschedule+0x21/0x36()
| Modules linked in:
| Pid: 27483, comm: cc1 Not tainted 2.6.26-rc7 #1
| [...]
| [<c0110355>] native_smp_send_reschedule+0x21/0x36
| [<c014fe8f>] force_quiescent_state+0x47/0x57
| [<c014fef0>] call_rcu+0x51/0x6d
| [<c01713b3>] __fput+0x130/0x158
| [<c0171231>] fput+0x17/0x19
| [<c016fd99>] filp_close+0x4d/0x57
| [<c016fdff>] sys_close+0x5c/0x97
IMHO the warning is a spurious one.
cpu_online_map is updated by the _cpu_down() using stop_machine_run().
Since force_quiescent_state is invoked from irqs disabled section,
stop_machine_run() won't be executing while a cpu is executing
force_quiescent_state(). Hence the cpu_online_map is stable while we're
in the irq disabled section.
However, a cpu might have been offlined _just_ before we disabled irqs
while entering force_quiescent_state(). And rcu subsystem might not yet
have handled the CPU_DEAD notification, leading to the offlined cpu's
bit being set in the rcp->cpumask.
Hence cpumask = (rcp->cpumask & cpu_online_map) to prevent sending
smp_reschedule() to an offlined CPU.
Here's the timeline:
CPU_A CPU_B
--------------------------------------------------------------
cpu_down(): .
. .
. .
stop_machine(): /* disables preemption, .
* and irqs */ .
. .
. .
take_cpu_down(); .
. .
. .
. .
cpu_disable(); /*this removes cpu .
*from cpu_online_map .
*/ .
. .
. .
restart_machine(); /* enables irqs */ .
------WINDOW DURING WHICH rcp->cpumask is stale ---------------
. call_rcu();
. /* disables irqs here */
. .force_quiescent_state();
.CPU_DEAD: .for_each_cpu(rcp->cpumask)
. . smp_send_reschedule();
. .
. . WARN_ON() for offlined CPU!
.
.
.
rcu_cpu_notify:
.
-------- WINDOW ENDS ------------------------------------------
rcu_offline_cpu() /* Which calls cpu_quiet()
* which removes
* cpu from rcp->cpumask.
*/
If a new batch was started just before calling stop_machine_run(), the
"tobe-offlined" cpu is still present in rcp-cpumask.
During a cpu-offline, from take_cpu_down(), we queue an rt-prio idle
task as the next task to be picked by the scheduler. We also call
cpu_disable() which will disable any further interrupts and remove the
cpu's bit from the cpu_online_map.
Once the stop_machine_run() successfully calls take_cpu_down(), it calls
schedule(). That's the last time a schedule is called on the offlined
cpu, and hence the last time when rdp->passed_quiesc will be set to 1
through rcu_qsctr_inc().
But the cpu_quiet() will be on this cpu will be called only when the
next RCU_SOFTIRQ occurs on this CPU. So at this time, the offlined CPU
is still set in rcp->cpumask.
Now coming back to the idle_task which truely offlines the CPU, it does
check for a pending RCU and raises the softirq, since it will find
rdp->passed_quiesc to be 0 in this case. However, since the cpu is
offline I am not sure if the softirq will trigger on the CPU.
Even if it doesn't the rcu_offline_cpu() will find that rcp->completed
is not the same as rcp->cur, which means that our cpu could be holding
up the grace period progression. Hence we call cpu_quiet() and move
ahead.
But because of the window explained in the timeline, we could still have
a call_rcu() before the RCU subsystem executes it's CPU_DEAD
notification, and we send smp_send_reschedule() to offlined cpu while
trying to force the quiescent states. The appended patch adds comments
and prevents checking for offlined cpu everytime.
cpu_online_map is updated by the _cpu_down() using stop_machine_run().
Since force_quiescent_state is invoked from irqs disabled section,
stop_machine_run() won't be executing while a cpu is executing
force_quiescent_state(). Hence the cpu_online_map is stable while we're
in the irq disabled section.
Reported-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
Acked-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rusty Russel <rusty@rustcorp.com.au>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-26 22:47:38 -06:00
|
|
|
*
|
|
|
|
* cpu_online_map is updated by the _cpu_down()
|
2008-07-28 11:16:30 -06:00
|
|
|
* using __stop_machine(). Since we're in irqs disabled
|
|
|
|
* section, __stop_machine() is not exectuting, hence
|
rcu: fix hotplug vs rcu race
Dhaval Giani reported this warning during cpu hotplug stress-tests:
| On running kernel compiles in parallel with cpu hotplug:
|
| WARNING: at arch/x86/kernel/smp.c:118
| native_smp_send_reschedule+0x21/0x36()
| Modules linked in:
| Pid: 27483, comm: cc1 Not tainted 2.6.26-rc7 #1
| [...]
| [<c0110355>] native_smp_send_reschedule+0x21/0x36
| [<c014fe8f>] force_quiescent_state+0x47/0x57
| [<c014fef0>] call_rcu+0x51/0x6d
| [<c01713b3>] __fput+0x130/0x158
| [<c0171231>] fput+0x17/0x19
| [<c016fd99>] filp_close+0x4d/0x57
| [<c016fdff>] sys_close+0x5c/0x97
IMHO the warning is a spurious one.
cpu_online_map is updated by the _cpu_down() using stop_machine_run().
Since force_quiescent_state is invoked from irqs disabled section,
stop_machine_run() won't be executing while a cpu is executing
force_quiescent_state(). Hence the cpu_online_map is stable while we're
in the irq disabled section.
However, a cpu might have been offlined _just_ before we disabled irqs
while entering force_quiescent_state(). And rcu subsystem might not yet
have handled the CPU_DEAD notification, leading to the offlined cpu's
bit being set in the rcp->cpumask.
Hence cpumask = (rcp->cpumask & cpu_online_map) to prevent sending
smp_reschedule() to an offlined CPU.
Here's the timeline:
CPU_A CPU_B
--------------------------------------------------------------
cpu_down(): .
. .
. .
stop_machine(): /* disables preemption, .
* and irqs */ .
. .
. .
take_cpu_down(); .
. .
. .
. .
cpu_disable(); /*this removes cpu .
*from cpu_online_map .
*/ .
. .
. .
restart_machine(); /* enables irqs */ .
------WINDOW DURING WHICH rcp->cpumask is stale ---------------
. call_rcu();
. /* disables irqs here */
. .force_quiescent_state();
.CPU_DEAD: .for_each_cpu(rcp->cpumask)
. . smp_send_reschedule();
. .
. . WARN_ON() for offlined CPU!
.
.
.
rcu_cpu_notify:
.
-------- WINDOW ENDS ------------------------------------------
rcu_offline_cpu() /* Which calls cpu_quiet()
* which removes
* cpu from rcp->cpumask.
*/
If a new batch was started just before calling stop_machine_run(), the
"tobe-offlined" cpu is still present in rcp-cpumask.
During a cpu-offline, from take_cpu_down(), we queue an rt-prio idle
task as the next task to be picked by the scheduler. We also call
cpu_disable() which will disable any further interrupts and remove the
cpu's bit from the cpu_online_map.
Once the stop_machine_run() successfully calls take_cpu_down(), it calls
schedule(). That's the last time a schedule is called on the offlined
cpu, and hence the last time when rdp->passed_quiesc will be set to 1
through rcu_qsctr_inc().
But the cpu_quiet() will be on this cpu will be called only when the
next RCU_SOFTIRQ occurs on this CPU. So at this time, the offlined CPU
is still set in rcp->cpumask.
Now coming back to the idle_task which truely offlines the CPU, it does
check for a pending RCU and raises the softirq, since it will find
rdp->passed_quiesc to be 0 in this case. However, since the cpu is
offline I am not sure if the softirq will trigger on the CPU.
Even if it doesn't the rcu_offline_cpu() will find that rcp->completed
is not the same as rcp->cur, which means that our cpu could be holding
up the grace period progression. Hence we call cpu_quiet() and move
ahead.
But because of the window explained in the timeline, we could still have
a call_rcu() before the RCU subsystem executes it's CPU_DEAD
notification, and we send smp_send_reschedule() to offlined cpu while
trying to force the quiescent states. The appended patch adds comments
and prevents checking for offlined cpu everytime.
cpu_online_map is updated by the _cpu_down() using stop_machine_run().
Since force_quiescent_state is invoked from irqs disabled section,
stop_machine_run() won't be executing while a cpu is executing
force_quiescent_state(). Hence the cpu_online_map is stable while we're
in the irq disabled section.
Reported-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
Acked-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rusty Russel <rusty@rustcorp.com.au>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-26 22:47:38 -06:00
|
|
|
* the cpu_online_map is stable.
|
|
|
|
*
|
|
|
|
* However, a cpu might have been offlined _just_ before
|
|
|
|
* we disabled irqs while entering here.
|
|
|
|
* And rcu subsystem might not yet have handled the CPU_DEAD
|
|
|
|
* notification, leading to the offlined cpu's bit
|
|
|
|
* being set in the rcp->cpumask.
|
|
|
|
*
|
|
|
|
* Hence cpumask = (rcp->cpumask & cpu_online_map) to prevent
|
|
|
|
* sending smp_reschedule() to an offlined CPU.
|
2008-01-25 13:08:24 -07:00
|
|
|
*/
|
rcu: fix hotplug vs rcu race
Dhaval Giani reported this warning during cpu hotplug stress-tests:
| On running kernel compiles in parallel with cpu hotplug:
|
| WARNING: at arch/x86/kernel/smp.c:118
| native_smp_send_reschedule+0x21/0x36()
| Modules linked in:
| Pid: 27483, comm: cc1 Not tainted 2.6.26-rc7 #1
| [...]
| [<c0110355>] native_smp_send_reschedule+0x21/0x36
| [<c014fe8f>] force_quiescent_state+0x47/0x57
| [<c014fef0>] call_rcu+0x51/0x6d
| [<c01713b3>] __fput+0x130/0x158
| [<c0171231>] fput+0x17/0x19
| [<c016fd99>] filp_close+0x4d/0x57
| [<c016fdff>] sys_close+0x5c/0x97
IMHO the warning is a spurious one.
cpu_online_map is updated by the _cpu_down() using stop_machine_run().
Since force_quiescent_state is invoked from irqs disabled section,
stop_machine_run() won't be executing while a cpu is executing
force_quiescent_state(). Hence the cpu_online_map is stable while we're
in the irq disabled section.
However, a cpu might have been offlined _just_ before we disabled irqs
while entering force_quiescent_state(). And rcu subsystem might not yet
have handled the CPU_DEAD notification, leading to the offlined cpu's
bit being set in the rcp->cpumask.
Hence cpumask = (rcp->cpumask & cpu_online_map) to prevent sending
smp_reschedule() to an offlined CPU.
Here's the timeline:
CPU_A CPU_B
--------------------------------------------------------------
cpu_down(): .
. .
. .
stop_machine(): /* disables preemption, .
* and irqs */ .
. .
. .
take_cpu_down(); .
. .
. .
. .
cpu_disable(); /*this removes cpu .
*from cpu_online_map .
*/ .
. .
. .
restart_machine(); /* enables irqs */ .
------WINDOW DURING WHICH rcp->cpumask is stale ---------------
. call_rcu();
. /* disables irqs here */
. .force_quiescent_state();
.CPU_DEAD: .for_each_cpu(rcp->cpumask)
. . smp_send_reschedule();
. .
. . WARN_ON() for offlined CPU!
.
.
.
rcu_cpu_notify:
.
-------- WINDOW ENDS ------------------------------------------
rcu_offline_cpu() /* Which calls cpu_quiet()
* which removes
* cpu from rcp->cpumask.
*/
If a new batch was started just before calling stop_machine_run(), the
"tobe-offlined" cpu is still present in rcp-cpumask.
During a cpu-offline, from take_cpu_down(), we queue an rt-prio idle
task as the next task to be picked by the scheduler. We also call
cpu_disable() which will disable any further interrupts and remove the
cpu's bit from the cpu_online_map.
Once the stop_machine_run() successfully calls take_cpu_down(), it calls
schedule(). That's the last time a schedule is called on the offlined
cpu, and hence the last time when rdp->passed_quiesc will be set to 1
through rcu_qsctr_inc().
But the cpu_quiet() will be on this cpu will be called only when the
next RCU_SOFTIRQ occurs on this CPU. So at this time, the offlined CPU
is still set in rcp->cpumask.
Now coming back to the idle_task which truely offlines the CPU, it does
check for a pending RCU and raises the softirq, since it will find
rdp->passed_quiesc to be 0 in this case. However, since the cpu is
offline I am not sure if the softirq will trigger on the CPU.
Even if it doesn't the rcu_offline_cpu() will find that rcp->completed
is not the same as rcp->cur, which means that our cpu could be holding
up the grace period progression. Hence we call cpu_quiet() and move
ahead.
But because of the window explained in the timeline, we could still have
a call_rcu() before the RCU subsystem executes it's CPU_DEAD
notification, and we send smp_send_reschedule() to offlined cpu while
trying to force the quiescent states. The appended patch adds comments
and prevents checking for offlined cpu everytime.
cpu_online_map is updated by the _cpu_down() using stop_machine_run().
Since force_quiescent_state is invoked from irqs disabled section,
stop_machine_run() won't be executing while a cpu is executing
force_quiescent_state(). Hence the cpu_online_map is stable while we're
in the irq disabled section.
Reported-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
Acked-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rusty Russel <rusty@rustcorp.com.au>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-26 22:47:38 -06:00
|
|
|
cpus_and(cpumask, rcp->cpumask, cpu_online_map);
|
2008-01-25 13:08:24 -07:00
|
|
|
cpu_clear(rdp->cpu, cpumask);
|
2008-05-12 13:21:13 -06:00
|
|
|
for_each_cpu_mask_nr(cpu, cpumask)
|
2008-01-25 13:08:24 -07:00
|
|
|
smp_send_reschedule(cpu);
|
|
|
|
}
|
2008-08-05 10:21:44 -06:00
|
|
|
spin_unlock(&rcp->lock);
|
2008-01-25 13:08:24 -07:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void force_quiescent_state(struct rcu_data *rdp,
|
|
|
|
struct rcu_ctrlblk *rcp)
|
|
|
|
{
|
|
|
|
set_need_resched();
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
static void __call_rcu(struct rcu_head *head, struct rcu_ctrlblk *rcp,
|
|
|
|
struct rcu_data *rdp)
|
|
|
|
{
|
|
|
|
long batch;
|
2008-08-05 10:21:44 -06:00
|
|
|
|
|
|
|
head->next = NULL;
|
|
|
|
smp_mb(); /* Read of rcu->cur must happen after any change by caller. */
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Determine the batch number of this callback.
|
|
|
|
*
|
|
|
|
* Using ACCESS_ONCE to avoid the following error when gcc eliminates
|
|
|
|
* local variable "batch" and emits codes like this:
|
|
|
|
* 1) rdp->batch = rcp->cur + 1 # gets old value
|
|
|
|
* ......
|
|
|
|
* 2)rcu_batch_after(rcp->cur + 1, rdp->batch) # gets new value
|
|
|
|
* then [*nxttail[0], *nxttail[1]) may contain callbacks
|
|
|
|
* that batch# = rdp->batch, see the comment of struct rcu_data.
|
|
|
|
*/
|
|
|
|
batch = ACCESS_ONCE(rcp->cur) + 1;
|
|
|
|
|
|
|
|
if (rdp->nxtlist && rcu_batch_after(batch, rdp->batch)) {
|
|
|
|
/* process callbacks */
|
|
|
|
rdp->nxttail[0] = rdp->nxttail[1];
|
|
|
|
rdp->nxttail[1] = rdp->nxttail[2];
|
|
|
|
if (rcu_batch_after(batch - 1, rdp->batch))
|
|
|
|
rdp->nxttail[0] = rdp->nxttail[2];
|
|
|
|
}
|
|
|
|
|
|
|
|
rdp->batch = batch;
|
|
|
|
*rdp->nxttail[2] = head;
|
|
|
|
rdp->nxttail[2] = &head->next;
|
|
|
|
|
|
|
|
if (unlikely(++rdp->qlen > qhimark)) {
|
|
|
|
rdp->blimit = INT_MAX;
|
|
|
|
force_quiescent_state(rdp, &rcu_ctrlblk);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-01-25 13:08:24 -07:00
|
|
|
/**
|
|
|
|
* call_rcu - Queue an RCU callback for invocation after a grace period.
|
|
|
|
* @head: structure to be used for queueing the RCU updates.
|
|
|
|
* @func: actual update function to be invoked after the grace period
|
|
|
|
*
|
|
|
|
* The update function will be invoked some time after a full grace
|
|
|
|
* period elapses, in other words after all currently executing RCU
|
|
|
|
* read-side critical sections have completed. RCU read-side critical
|
|
|
|
* sections are delimited by rcu_read_lock() and rcu_read_unlock(),
|
|
|
|
* and may be nested.
|
|
|
|
*/
|
|
|
|
void call_rcu(struct rcu_head *head,
|
|
|
|
void (*func)(struct rcu_head *rcu))
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
head->func = func;
|
|
|
|
local_irq_save(flags);
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
__call_rcu(head, &rcu_ctrlblk, &__get_cpu_var(rcu_data));
|
2008-01-25 13:08:24 -07:00
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(call_rcu);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* call_rcu_bh - Queue an RCU for invocation after a quicker grace period.
|
|
|
|
* @head: structure to be used for queueing the RCU updates.
|
|
|
|
* @func: actual update function to be invoked after the grace period
|
|
|
|
*
|
|
|
|
* The update function will be invoked some time after a full grace
|
|
|
|
* period elapses, in other words after all currently executing RCU
|
|
|
|
* read-side critical sections have completed. call_rcu_bh() assumes
|
|
|
|
* that the read-side critical sections end on completion of a softirq
|
|
|
|
* handler. This means that read-side critical sections in process
|
|
|
|
* context must not be interrupted by softirqs. This interface is to be
|
|
|
|
* used when most of the read-side critical sections are in softirq context.
|
|
|
|
* RCU read-side critical sections are delimited by rcu_read_lock() and
|
|
|
|
* rcu_read_unlock(), * if in interrupt context or rcu_read_lock_bh()
|
|
|
|
* and rcu_read_unlock_bh(), if in process context. These may be nested.
|
|
|
|
*/
|
|
|
|
void call_rcu_bh(struct rcu_head *head,
|
|
|
|
void (*func)(struct rcu_head *rcu))
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
head->func = func;
|
|
|
|
local_irq_save(flags);
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
__call_rcu(head, &rcu_bh_ctrlblk, &__get_cpu_var(rcu_bh_data));
|
2008-01-25 13:08:24 -07:00
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(call_rcu_bh);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the number of RCU batches processed thus far. Useful
|
|
|
|
* for debug and statistics.
|
|
|
|
*/
|
|
|
|
long rcu_batches_completed(void)
|
|
|
|
{
|
|
|
|
return rcu_ctrlblk.completed;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_batches_completed);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the number of RCU batches processed thus far. Useful
|
|
|
|
* for debug and statistics.
|
|
|
|
*/
|
|
|
|
long rcu_batches_completed_bh(void)
|
|
|
|
{
|
|
|
|
return rcu_bh_ctrlblk.completed;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_batches_completed_bh);
|
|
|
|
|
|
|
|
/* Raises the softirq for processing rcu_callbacks. */
|
|
|
|
static inline void raise_rcu_softirq(void)
|
|
|
|
{
|
|
|
|
raise_softirq(RCU_SOFTIRQ);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Invoke the completed RCU callbacks. They are expected to be in
|
|
|
|
* a per-cpu list.
|
|
|
|
*/
|
|
|
|
static void rcu_do_batch(struct rcu_data *rdp)
|
|
|
|
{
|
|
|
|
struct rcu_head *next, *list;
|
|
|
|
int count = 0;
|
|
|
|
|
|
|
|
list = rdp->donelist;
|
|
|
|
while (list) {
|
|
|
|
next = list->next;
|
|
|
|
prefetch(next);
|
|
|
|
list->func(list);
|
|
|
|
list = next;
|
|
|
|
if (++count >= rdp->blimit)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
rdp->donelist = list;
|
|
|
|
|
|
|
|
local_irq_disable();
|
|
|
|
rdp->qlen -= count;
|
|
|
|
local_irq_enable();
|
|
|
|
if (rdp->blimit == INT_MAX && rdp->qlen <= qlowmark)
|
|
|
|
rdp->blimit = blimit;
|
|
|
|
|
|
|
|
if (!rdp->donelist)
|
|
|
|
rdp->donetail = &rdp->donelist;
|
|
|
|
else
|
|
|
|
raise_rcu_softirq();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Grace period handling:
|
|
|
|
* The grace period handling consists out of two steps:
|
|
|
|
* - A new grace period is started.
|
|
|
|
* This is done by rcu_start_batch. The start is not broadcasted to
|
|
|
|
* all cpus, they must pick this up by comparing rcp->cur with
|
|
|
|
* rdp->quiescbatch. All cpus are recorded in the
|
|
|
|
* rcu_ctrlblk.cpumask bitmap.
|
|
|
|
* - All cpus must go through a quiescent state.
|
|
|
|
* Since the start of the grace period is not broadcasted, at least two
|
|
|
|
* calls to rcu_check_quiescent_state are required:
|
|
|
|
* The first call just notices that a new grace period is running. The
|
|
|
|
* following calls check if there was a quiescent state since the beginning
|
|
|
|
* of the grace period. If so, it updates rcu_ctrlblk.cpumask. If
|
|
|
|
* the bitmap is empty, then the grace period is completed.
|
|
|
|
* rcu_check_quiescent_state calls rcu_start_batch(0) to start the next grace
|
|
|
|
* period (if necessary).
|
|
|
|
*/
|
2008-08-10 19:35:38 -06:00
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_RCU_STALL
|
|
|
|
|
|
|
|
static inline void record_gp_check_time(struct rcu_ctrlblk *rcp)
|
|
|
|
{
|
|
|
|
rcp->gp_check = get_seconds() + 3;
|
|
|
|
}
|
2008-08-11 05:34:15 -06:00
|
|
|
|
2008-08-10 19:35:38 -06:00
|
|
|
static void print_other_cpu_stall(struct rcu_ctrlblk *rcp)
|
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
long delta;
|
|
|
|
|
|
|
|
/* Only let one CPU complain about others per time interval. */
|
|
|
|
|
|
|
|
spin_lock(&rcp->lock);
|
|
|
|
delta = get_seconds() - rcp->gp_check;
|
2008-08-11 05:34:15 -06:00
|
|
|
if (delta < 2L || cpus_empty(rcp->cpumask)) {
|
2008-08-10 19:35:38 -06:00
|
|
|
spin_unlock(&rcp->lock);
|
|
|
|
return;
|
|
|
|
}
|
2008-08-12 18:25:03 -06:00
|
|
|
rcp->gp_check = get_seconds() + 30;
|
2008-08-10 19:35:38 -06:00
|
|
|
spin_unlock(&rcp->lock);
|
|
|
|
|
|
|
|
/* OK, time to rat on our buddy... */
|
|
|
|
|
|
|
|
printk(KERN_ERR "RCU detected CPU stalls:");
|
|
|
|
for_each_cpu_mask(cpu, rcp->cpumask)
|
|
|
|
printk(" %d", cpu);
|
|
|
|
printk(" (detected by %d, t=%lu/%lu)\n",
|
|
|
|
smp_processor_id(), get_seconds(), rcp->gp_check);
|
|
|
|
}
|
2008-08-11 05:34:15 -06:00
|
|
|
|
2008-08-10 19:35:38 -06:00
|
|
|
static void print_cpu_stall(struct rcu_ctrlblk *rcp)
|
|
|
|
{
|
|
|
|
printk(KERN_ERR "RCU detected CPU %d stall (t=%lu/%lu)\n",
|
|
|
|
smp_processor_id(), get_seconds(), rcp->gp_check);
|
|
|
|
dump_stack();
|
|
|
|
spin_lock(&rcp->lock);
|
|
|
|
if ((long)(get_seconds() - rcp->gp_check) >= 0L)
|
|
|
|
rcp->gp_check = get_seconds() + 30;
|
|
|
|
spin_unlock(&rcp->lock);
|
|
|
|
}
|
2008-08-11 05:34:15 -06:00
|
|
|
|
|
|
|
static void check_cpu_stall(struct rcu_ctrlblk *rcp, struct rcu_data *rdp)
|
2008-08-10 19:35:38 -06:00
|
|
|
{
|
|
|
|
long delta;
|
|
|
|
|
|
|
|
delta = get_seconds() - rcp->gp_check;
|
|
|
|
if (cpu_isset(smp_processor_id(), rcp->cpumask) && delta >= 0L) {
|
|
|
|
|
|
|
|
/* We haven't checked in, so go dump stack. */
|
|
|
|
|
|
|
|
print_cpu_stall(rcp);
|
|
|
|
|
2008-08-11 05:34:15 -06:00
|
|
|
} else {
|
|
|
|
if (!cpus_empty(rcp->cpumask) && delta >= 2L) {
|
|
|
|
/* They had two seconds to dump stack, so complain. */
|
|
|
|
print_other_cpu_stall(rcp);
|
|
|
|
}
|
2008-08-10 19:35:38 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#else /* #ifdef CONFIG_DEBUG_RCU_STALL */
|
|
|
|
|
|
|
|
static inline void record_gp_check_time(struct rcu_ctrlblk *rcp)
|
|
|
|
{
|
|
|
|
}
|
2008-08-11 05:34:15 -06:00
|
|
|
|
|
|
|
static inline void
|
|
|
|
check_cpu_stall(struct rcu_ctrlblk *rcp, struct rcu_data *rdp)
|
2008-08-10 19:35:38 -06:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* #else #ifdef CONFIG_DEBUG_RCU_STALL */
|
|
|
|
|
2008-01-25 13:08:24 -07:00
|
|
|
/*
|
|
|
|
* Register a new batch of callbacks, and start it up if there is currently no
|
|
|
|
* active batch and the batch to be registered has not already occurred.
|
|
|
|
* Caller must hold rcu_ctrlblk.lock.
|
|
|
|
*/
|
|
|
|
static void rcu_start_batch(struct rcu_ctrlblk *rcp)
|
|
|
|
{
|
2008-07-06 03:23:55 -06:00
|
|
|
if (rcp->cur != rcp->pending &&
|
2008-01-25 13:08:24 -07:00
|
|
|
rcp->completed == rcp->cur) {
|
|
|
|
rcp->cur++;
|
2008-08-10 19:35:38 -06:00
|
|
|
record_gp_check_time(rcp);
|
2008-01-25 13:08:24 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Accessing nohz_cpu_mask before incrementing rcp->cur needs a
|
|
|
|
* Barrier Otherwise it can cause tickless idle CPUs to be
|
|
|
|
* included in rcp->cpumask, which will extend graceperiods
|
|
|
|
* unnecessarily.
|
|
|
|
*/
|
|
|
|
smp_mb();
|
|
|
|
cpus_andnot(rcp->cpumask, cpu_online_map, nohz_cpu_mask);
|
|
|
|
|
|
|
|
rcp->signaled = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* cpu went through a quiescent state since the beginning of the grace period.
|
|
|
|
* Clear it from the cpu mask and complete the grace period if it was the last
|
|
|
|
* cpu. Start another grace period if someone has further entries pending
|
|
|
|
*/
|
|
|
|
static void cpu_quiet(int cpu, struct rcu_ctrlblk *rcp)
|
|
|
|
{
|
|
|
|
cpu_clear(cpu, rcp->cpumask);
|
|
|
|
if (cpus_empty(rcp->cpumask)) {
|
|
|
|
/* batch completed ! */
|
|
|
|
rcp->completed = rcp->cur;
|
|
|
|
rcu_start_batch(rcp);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if the cpu has gone through a quiescent state (say context
|
|
|
|
* switch). If so and if it already hasn't done so in this RCU
|
|
|
|
* quiescent cycle, then indicate that it has done so.
|
|
|
|
*/
|
|
|
|
static void rcu_check_quiescent_state(struct rcu_ctrlblk *rcp,
|
|
|
|
struct rcu_data *rdp)
|
|
|
|
{
|
|
|
|
if (rdp->quiescbatch != rcp->cur) {
|
|
|
|
/* start new grace period: */
|
|
|
|
rdp->qs_pending = 1;
|
|
|
|
rdp->passed_quiesc = 0;
|
|
|
|
rdp->quiescbatch = rcp->cur;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Grace period already completed for this cpu?
|
|
|
|
* qs_pending is checked instead of the actual bitmap to avoid
|
|
|
|
* cacheline trashing.
|
|
|
|
*/
|
|
|
|
if (!rdp->qs_pending)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Was there a quiescent state since the beginning of the grace
|
|
|
|
* period? If no, then exit and wait for the next call.
|
|
|
|
*/
|
|
|
|
if (!rdp->passed_quiesc)
|
|
|
|
return;
|
|
|
|
rdp->qs_pending = 0;
|
|
|
|
|
|
|
|
spin_lock(&rcp->lock);
|
|
|
|
/*
|
|
|
|
* rdp->quiescbatch/rcp->cur and the cpu bitmap can come out of sync
|
|
|
|
* during cpu startup. Ignore the quiescent state.
|
|
|
|
*/
|
|
|
|
if (likely(rdp->quiescbatch == rcp->cur))
|
|
|
|
cpu_quiet(rdp->cpu, rcp);
|
|
|
|
|
|
|
|
spin_unlock(&rcp->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_HOTPLUG_CPU
|
|
|
|
|
|
|
|
/* warning! helper for rcu_offline_cpu. do not use elsewhere without reviewing
|
|
|
|
* locking requirements, the list it's pulling from has to belong to a cpu
|
|
|
|
* which is dead and hence not processing interrupts.
|
|
|
|
*/
|
|
|
|
static void rcu_move_batch(struct rcu_data *this_rdp, struct rcu_head *list,
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
struct rcu_head **tail, long batch)
|
2008-01-25 13:08:24 -07:00
|
|
|
{
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
if (list) {
|
|
|
|
local_irq_disable();
|
|
|
|
this_rdp->batch = batch;
|
|
|
|
*this_rdp->nxttail[2] = list;
|
|
|
|
this_rdp->nxttail[2] = tail;
|
|
|
|
local_irq_enable();
|
|
|
|
}
|
2008-01-25 13:08:24 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __rcu_offline_cpu(struct rcu_data *this_rdp,
|
|
|
|
struct rcu_ctrlblk *rcp, struct rcu_data *rdp)
|
|
|
|
{
|
2008-08-05 10:21:44 -06:00
|
|
|
/*
|
|
|
|
* if the cpu going offline owns the grace period
|
2008-01-25 13:08:24 -07:00
|
|
|
* we can block indefinitely waiting for it, so flush
|
|
|
|
* it here
|
|
|
|
*/
|
|
|
|
spin_lock_bh(&rcp->lock);
|
|
|
|
if (rcp->cur != rcp->completed)
|
|
|
|
cpu_quiet(rdp->cpu, rcp);
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
rcu_move_batch(this_rdp, rdp->donelist, rdp->donetail, rcp->cur + 1);
|
|
|
|
rcu_move_batch(this_rdp, rdp->nxtlist, rdp->nxttail[2], rcp->cur + 1);
|
2008-08-05 10:21:44 -06:00
|
|
|
spin_unlock_bh(&rcp->lock);
|
2008-06-25 20:06:43 -06:00
|
|
|
|
|
|
|
local_irq_disable();
|
|
|
|
this_rdp->qlen += rdp->qlen;
|
|
|
|
local_irq_enable();
|
2008-01-25 13:08:24 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rcu_offline_cpu(int cpu)
|
|
|
|
{
|
|
|
|
struct rcu_data *this_rdp = &get_cpu_var(rcu_data);
|
|
|
|
struct rcu_data *this_bh_rdp = &get_cpu_var(rcu_bh_data);
|
|
|
|
|
|
|
|
__rcu_offline_cpu(this_rdp, &rcu_ctrlblk,
|
|
|
|
&per_cpu(rcu_data, cpu));
|
|
|
|
__rcu_offline_cpu(this_bh_rdp, &rcu_bh_ctrlblk,
|
|
|
|
&per_cpu(rcu_bh_data, cpu));
|
|
|
|
put_cpu_var(rcu_data);
|
|
|
|
put_cpu_var(rcu_bh_data);
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
static void rcu_offline_cpu(int cpu)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This does the RCU processing work from softirq context.
|
|
|
|
*/
|
|
|
|
static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp,
|
|
|
|
struct rcu_data *rdp)
|
|
|
|
{
|
2008-08-05 10:21:44 -06:00
|
|
|
long completed_snap;
|
|
|
|
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
if (rdp->nxtlist) {
|
2008-01-25 13:08:24 -07:00
|
|
|
local_irq_disable();
|
2008-08-05 10:21:44 -06:00
|
|
|
completed_snap = ACCESS_ONCE(rcp->completed);
|
2008-01-25 13:08:24 -07:00
|
|
|
|
|
|
|
/*
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
* move the other grace-period-completed entries to
|
|
|
|
* [rdp->nxtlist, *rdp->nxttail[0]) temporarily
|
|
|
|
*/
|
2008-08-05 10:21:44 -06:00
|
|
|
if (!rcu_batch_before(completed_snap, rdp->batch))
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
rdp->nxttail[0] = rdp->nxttail[1] = rdp->nxttail[2];
|
2008-08-05 10:21:44 -06:00
|
|
|
else if (!rcu_batch_before(completed_snap, rdp->batch - 1))
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
rdp->nxttail[0] = rdp->nxttail[1];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* the grace period for entries in
|
|
|
|
* [rdp->nxtlist, *rdp->nxttail[0]) has completed and
|
|
|
|
* move these entries to donelist
|
2008-01-25 13:08:24 -07:00
|
|
|
*/
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
if (rdp->nxttail[0] != &rdp->nxtlist) {
|
|
|
|
*rdp->donetail = rdp->nxtlist;
|
|
|
|
rdp->donetail = rdp->nxttail[0];
|
|
|
|
rdp->nxtlist = *rdp->nxttail[0];
|
|
|
|
*rdp->donetail = NULL;
|
|
|
|
|
|
|
|
if (rdp->nxttail[1] == rdp->nxttail[0])
|
|
|
|
rdp->nxttail[1] = &rdp->nxtlist;
|
|
|
|
if (rdp->nxttail[2] == rdp->nxttail[0])
|
|
|
|
rdp->nxttail[2] = &rdp->nxtlist;
|
|
|
|
rdp->nxttail[0] = &rdp->nxtlist;
|
|
|
|
}
|
2008-01-25 13:08:24 -07:00
|
|
|
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
local_irq_enable();
|
2008-01-25 13:08:24 -07:00
|
|
|
|
2008-07-06 03:23:55 -06:00
|
|
|
if (rcu_batch_after(rdp->batch, rcp->pending)) {
|
2008-01-25 13:08:24 -07:00
|
|
|
/* and start it/schedule start if it's a new batch */
|
|
|
|
spin_lock(&rcp->lock);
|
2008-07-06 03:23:55 -06:00
|
|
|
if (rcu_batch_after(rdp->batch, rcp->pending)) {
|
|
|
|
rcp->pending = rdp->batch;
|
|
|
|
rcu_start_batch(rcp);
|
|
|
|
}
|
2008-01-25 13:08:24 -07:00
|
|
|
spin_unlock(&rcp->lock);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rcu_check_quiescent_state(rcp, rdp);
|
|
|
|
if (rdp->donelist)
|
|
|
|
rcu_do_batch(rdp);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rcu_process_callbacks(struct softirq_action *unused)
|
|
|
|
{
|
2008-08-05 10:21:44 -06:00
|
|
|
/*
|
|
|
|
* Memory references from any prior RCU read-side critical sections
|
|
|
|
* executed by the interrupted code must be see before any RCU
|
|
|
|
* grace-period manupulations below.
|
|
|
|
*/
|
|
|
|
|
|
|
|
smp_mb(); /* See above block comment. */
|
|
|
|
|
2008-01-25 13:08:24 -07:00
|
|
|
__rcu_process_callbacks(&rcu_ctrlblk, &__get_cpu_var(rcu_data));
|
|
|
|
__rcu_process_callbacks(&rcu_bh_ctrlblk, &__get_cpu_var(rcu_bh_data));
|
2008-08-05 10:21:44 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Memory references from any later RCU read-side critical sections
|
|
|
|
* executed by the interrupted code must be see after any RCU
|
|
|
|
* grace-period manupulations above.
|
|
|
|
*/
|
|
|
|
|
|
|
|
smp_mb(); /* See above block comment. */
|
2008-01-25 13:08:24 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __rcu_pending(struct rcu_ctrlblk *rcp, struct rcu_data *rdp)
|
|
|
|
{
|
2008-08-10 19:35:38 -06:00
|
|
|
/* Check for CPU stalls, if enabled. */
|
|
|
|
check_cpu_stall(rcp, rdp);
|
|
|
|
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
if (rdp->nxtlist) {
|
2008-08-05 10:21:44 -06:00
|
|
|
long completed_snap = ACCESS_ONCE(rcp->completed);
|
|
|
|
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
/*
|
|
|
|
* This cpu has pending rcu entries and the grace period
|
|
|
|
* for them has completed.
|
|
|
|
*/
|
2008-08-05 10:21:44 -06:00
|
|
|
if (!rcu_batch_before(completed_snap, rdp->batch))
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
return 1;
|
2008-08-05 10:21:44 -06:00
|
|
|
if (!rcu_batch_before(completed_snap, rdp->batch - 1) &&
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
rdp->nxttail[0] != rdp->nxttail[1])
|
|
|
|
return 1;
|
|
|
|
if (rdp->nxttail[0] != &rdp->nxtlist)
|
|
|
|
return 1;
|
2008-01-25 13:08:24 -07:00
|
|
|
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
/*
|
|
|
|
* This cpu has pending rcu entries and the new batch
|
|
|
|
* for then hasn't been started nor scheduled start
|
|
|
|
*/
|
|
|
|
if (rcu_batch_after(rdp->batch, rcp->pending))
|
|
|
|
return 1;
|
|
|
|
}
|
2008-01-25 13:08:24 -07:00
|
|
|
|
|
|
|
/* This cpu has finished callbacks to invoke */
|
|
|
|
if (rdp->donelist)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
/* The rcu core waits for a quiescent state from the cpu */
|
|
|
|
if (rdp->quiescbatch != rcp->cur || rdp->qs_pending)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
/* nothing to do */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to see if there is any immediate RCU-related work to be done
|
|
|
|
* by the current CPU, returning 1 if so. This function is part of the
|
|
|
|
* RCU implementation; it is -not- an exported member of the RCU API.
|
|
|
|
*/
|
|
|
|
int rcu_pending(int cpu)
|
|
|
|
{
|
|
|
|
return __rcu_pending(&rcu_ctrlblk, &per_cpu(rcu_data, cpu)) ||
|
|
|
|
__rcu_pending(&rcu_bh_ctrlblk, &per_cpu(rcu_bh_data, cpu));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to see if any future RCU-related work will need to be done
|
|
|
|
* by the current CPU, even if none need be done immediately, returning
|
|
|
|
* 1 if so. This function is part of the RCU implementation; it is -not-
|
|
|
|
* an exported member of the RCU API.
|
|
|
|
*/
|
|
|
|
int rcu_needs_cpu(int cpu)
|
|
|
|
{
|
|
|
|
struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
|
|
|
|
struct rcu_data *rdp_bh = &per_cpu(rcu_bh_data, cpu);
|
|
|
|
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
return !!rdp->nxtlist || !!rdp_bh->nxtlist || rcu_pending(cpu);
|
2008-01-25 13:08:24 -07:00
|
|
|
}
|
|
|
|
|
2008-08-05 10:21:44 -06:00
|
|
|
/*
|
|
|
|
* Top-level function driving RCU grace-period detection, normally
|
|
|
|
* invoked from the scheduler-clock interrupt. This function simply
|
|
|
|
* increments counters that are read only from softirq by this same
|
|
|
|
* CPU, so there are no memory barriers required.
|
|
|
|
*/
|
2008-01-25 13:08:24 -07:00
|
|
|
void rcu_check_callbacks(int cpu, int user)
|
|
|
|
{
|
|
|
|
if (user ||
|
|
|
|
(idle_cpu(cpu) && !in_softirq() &&
|
|
|
|
hardirq_count() <= (1 << HARDIRQ_SHIFT))) {
|
2008-05-12 13:21:05 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Get here if this CPU took its interrupt from user
|
|
|
|
* mode or from the idle loop, and if this is not a
|
|
|
|
* nested interrupt. In this case, the CPU is in
|
|
|
|
* a quiescent state, so count it.
|
|
|
|
*
|
|
|
|
* Also do a memory barrier. This is needed to handle
|
|
|
|
* the case where writes from a preempt-disable section
|
|
|
|
* of code get reordered into schedule() by this CPU's
|
|
|
|
* write buffer. The memory barrier makes sure that
|
|
|
|
* the rcu_qsctr_inc() and rcu_bh_qsctr_inc() are see
|
|
|
|
* by other CPUs to happen after any such write.
|
|
|
|
*/
|
|
|
|
|
|
|
|
smp_mb(); /* See above block comment. */
|
2008-01-25 13:08:24 -07:00
|
|
|
rcu_qsctr_inc(cpu);
|
|
|
|
rcu_bh_qsctr_inc(cpu);
|
2008-05-12 13:21:05 -06:00
|
|
|
|
|
|
|
} else if (!in_softirq()) {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get here if this CPU did not take its interrupt from
|
|
|
|
* softirq, in other words, if it is not interrupting
|
|
|
|
* a rcu_bh read-side critical section. This is an _bh
|
|
|
|
* critical section, so count it. The memory barrier
|
|
|
|
* is needed for the same reason as is the above one.
|
|
|
|
*/
|
|
|
|
|
|
|
|
smp_mb(); /* See above block comment. */
|
2008-01-25 13:08:24 -07:00
|
|
|
rcu_bh_qsctr_inc(cpu);
|
2008-05-12 13:21:05 -06:00
|
|
|
}
|
2008-01-25 13:08:24 -07:00
|
|
|
raise_rcu_softirq();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rcu_init_percpu_data(int cpu, struct rcu_ctrlblk *rcp,
|
|
|
|
struct rcu_data *rdp)
|
|
|
|
{
|
2008-08-17 08:37:15 -06:00
|
|
|
long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&rcp->lock, flags);
|
2008-01-25 13:08:24 -07:00
|
|
|
memset(rdp, 0, sizeof(*rdp));
|
rcu classic: new algorithm for callbacks-processing(v2)
This is v2, it's a little deference from v1 that I
had send to lkml.
use ACCESS_ONCE
use rcu_batch_after/rcu_batch_before for batch # comparison.
rcutorture test result:
(hotplugs: do cpu-online/offline once per second)
No CONFIG_NO_HZ: OK, 12hours
No CONFIG_NO_HZ, hotplugs: OK, 12hours
CONFIG_NO_HZ=y: OK, 24hours
CONFIG_NO_HZ=y, hotplugs: Failed.
(Failed also without my patch applied, exactly the same bug occurred,
http://lkml.org/lkml/2008/7/3/24)
v1's email thread:
http://lkml.org/lkml/2008/6/2/539
v1's description:
The code/algorithm of the implement of current callbacks-processing
is very efficient and technical. But when I studied it and I found
a disadvantage:
In multi-CPU systems, when a new RCU callback is being
queued(call_rcu[_bh]), this callback will be invoked after the grace
period for the batch with batch number = rcp->cur+2 has completed
very very likely in current implement. Actually, this callback can be
invoked after the grace period for the batch with
batch number = rcp->cur+1 has completed. The delay of invocation means
that latency of synchronize_rcu() is extended. But more important thing
is that the callbacks usually free memory, and these works are delayed
too! it's necessary for reclaimer to free memory as soon as
possible when left memory is few.
A very simple way can solve this problem:
a field(struct rcu_head::batch) is added to record the batch number for
the RCU callback. And when a new RCU callback is being queued, we
determine the batch number for this callback(head->batch = rcp->cur+1)
and we move this callback to rdp->donelist if we find
that head->batch <= rcp->completed when we process callbacks.
This simple way reduces the wait time for invocation a lot. (about
2.5Grace Period -> 1.5Grace Period in average in multi-CPU systems)
This is my algorithm. But I do not add any field for struct rcu_head
in my implement. We just need to memorize the last 2 batches and
their batch number, because these 2 batches include all entries that
for whom the grace period hasn't completed. So we use a special
linked-list rather than add a field.
Please see the comment of struct rcu_data.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Gautham Shenoy <ego@in.ibm.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-06 03:23:59 -06:00
|
|
|
rdp->nxttail[0] = rdp->nxttail[1] = rdp->nxttail[2] = &rdp->nxtlist;
|
2008-01-25 13:08:24 -07:00
|
|
|
rdp->donetail = &rdp->donelist;
|
|
|
|
rdp->quiescbatch = rcp->completed;
|
|
|
|
rdp->qs_pending = 0;
|
|
|
|
rdp->cpu = cpu;
|
|
|
|
rdp->blimit = blimit;
|
2008-08-17 08:37:15 -06:00
|
|
|
spin_unlock_irqrestore(&rcp->lock, flags);
|
2008-01-25 13:08:24 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __cpuinit rcu_online_cpu(int cpu)
|
|
|
|
{
|
|
|
|
struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
|
|
|
|
struct rcu_data *bh_rdp = &per_cpu(rcu_bh_data, cpu);
|
|
|
|
|
|
|
|
rcu_init_percpu_data(cpu, &rcu_ctrlblk, rdp);
|
|
|
|
rcu_init_percpu_data(cpu, &rcu_bh_ctrlblk, bh_rdp);
|
Remove argument from open_softirq which is always NULL
As git-grep shows, open_softirq() is always called with the last argument
being NULL
block/blk-core.c: open_softirq(BLOCK_SOFTIRQ, blk_done_softirq, NULL);
kernel/hrtimer.c: open_softirq(HRTIMER_SOFTIRQ, run_hrtimer_softirq, NULL);
kernel/rcuclassic.c: open_softirq(RCU_SOFTIRQ, rcu_process_callbacks, NULL);
kernel/rcupreempt.c: open_softirq(RCU_SOFTIRQ, rcu_process_callbacks, NULL);
kernel/sched.c: open_softirq(SCHED_SOFTIRQ, run_rebalance_domains, NULL);
kernel/softirq.c: open_softirq(TASKLET_SOFTIRQ, tasklet_action, NULL);
kernel/softirq.c: open_softirq(HI_SOFTIRQ, tasklet_hi_action, NULL);
kernel/timer.c: open_softirq(TIMER_SOFTIRQ, run_timer_softirq, NULL);
net/core/dev.c: open_softirq(NET_TX_SOFTIRQ, net_tx_action, NULL);
net/core/dev.c: open_softirq(NET_RX_SOFTIRQ, net_rx_action, NULL);
This observation has already been made by Matthew Wilcox in June 2002
(http://www.cs.helsinki.fi/linux/linux-kernel/2002-25/0687.html)
"I notice that none of the current softirq routines use the data element
passed to them."
and the situation hasn't changed since them. So it appears we can safely
remove that extra argument to save 128 (54) bytes of kernel data (text).
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-15 08:15:37 -06:00
|
|
|
open_softirq(RCU_SOFTIRQ, rcu_process_callbacks);
|
2008-01-25 13:08:24 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __cpuinit rcu_cpu_notify(struct notifier_block *self,
|
|
|
|
unsigned long action, void *hcpu)
|
|
|
|
{
|
|
|
|
long cpu = (long)hcpu;
|
|
|
|
|
|
|
|
switch (action) {
|
|
|
|
case CPU_UP_PREPARE:
|
|
|
|
case CPU_UP_PREPARE_FROZEN:
|
|
|
|
rcu_online_cpu(cpu);
|
|
|
|
break;
|
|
|
|
case CPU_DEAD:
|
|
|
|
case CPU_DEAD_FROZEN:
|
|
|
|
rcu_offline_cpu(cpu);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return NOTIFY_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block __cpuinitdata rcu_nb = {
|
|
|
|
.notifier_call = rcu_cpu_notify,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initializes rcu mechanism. Assumed to be called early.
|
|
|
|
* That is before local timer(SMP) or jiffie timer (uniproc) is setup.
|
|
|
|
* Note that rcu_qsctr and friends are implicitly
|
|
|
|
* initialized due to the choice of ``0'' for RCU_CTR_INVALID.
|
|
|
|
*/
|
|
|
|
void __init __rcu_init(void)
|
|
|
|
{
|
|
|
|
rcu_cpu_notify(&rcu_nb, CPU_UP_PREPARE,
|
|
|
|
(void *)(long)smp_processor_id());
|
|
|
|
/* Register notifier for non-boot CPUs */
|
|
|
|
register_cpu_notifier(&rcu_nb);
|
|
|
|
}
|
|
|
|
|
|
|
|
module_param(blimit, int, 0);
|
|
|
|
module_param(qhimark, int, 0);
|
|
|
|
module_param(qlowmark, int, 0);
|