Commit 9711268c authored by Dipankar Sarma's avatar Dipankar Sarma Committed by Linus Torvalds

[PATCH] rcu: document RCU api

Patch from Paul for additional documentation of api.

Updated based on feedback, and to apply to 2.6.8-rc3.  I will be adding more
detailed documentation to the Documentation directory in a separate patch.
Signed-off-by: default avatarPaul McKenney <paulmck@us.ibm.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
parent 44d25f03
...@@ -154,9 +154,72 @@ static inline int rcu_pending(int cpu) ...@@ -154,9 +154,72 @@ static inline int rcu_pending(int cpu)
__rcu_pending(&rcu_bh_ctrlblk, &per_cpu(rcu_bh_data, cpu)); __rcu_pending(&rcu_bh_ctrlblk, &per_cpu(rcu_bh_data, cpu));
} }
/**
* rcu_read_lock - mark the beginning of an RCU read-side critical section.
*
* When synchronize_kernel() is invoked on one CPU while other CPUs
* are within RCU read-side critical sections, then the
* synchronize_kernel() is guaranteed to block until after all the other
* CPUs exit their critical sections. Similarly, if call_rcu() is invoked
* on one CPU while other CPUs are within RCU read-side critical
* sections, invocation of the corresponding RCU callback is deferred
* until after the all the other CPUs exit their critical sections.
*
* Note, however, that RCU callbacks are permitted to run concurrently
* with RCU read-side critical sections. One way that this can happen
* is via the following sequence of events: (1) CPU 0 enters an RCU
* read-side critical section, (2) CPU 1 invokes call_rcu() to register
* an RCU callback, (3) CPU 0 exits the RCU read-side critical section,
* (4) CPU 2 enters a RCU read-side critical section, (5) the RCU
* callback is invoked. This is legal, because the RCU read-side critical
* section that was running concurrently with the call_rcu() (and which
* therefore might be referencing something that the corresponding RCU
* callback would free up) has completed before the corresponding
* RCU callback is invoked.
*
* RCU read-side critical sections may be nested. Any deferred actions
* will be deferred until the outermost RCU read-side critical section
* completes.
*
* It is illegal to block while in an RCU read-side critical section.
*/
#define rcu_read_lock() preempt_disable() #define rcu_read_lock() preempt_disable()
/**
* rcu_read_unlock - marks the end of an RCU read-side critical section.
*
* See rcu_read_lock() for more information.
*/
#define rcu_read_unlock() preempt_enable() #define rcu_read_unlock() preempt_enable()
/*
* So where is rcu_write_lock()? It does not exist, as there is no
* way for writers to lock out RCU readers. This is a feature, not
* a bug -- this property is what provides RCU's performance benefits.
* Of course, writers must coordinate with each other. The normal
* spinlock primitives work well for this, but any other technique may be
* used as well. RCU does not care how the writers keep out of each
* others' way, as long as they do so.
*/
/**
* rcu_read_lock_bh - mark the beginning of a softirq-only RCU critical section
*
* This is equivalent of rcu_read_lock(), but to be used when updates
* are being done using call_rcu_bh(). Since call_rcu_bh() callbacks
* consider completion of a softirq handler to be a quiescent state,
* a process in RCU read-side critical section must be protected by
* disabling softirqs. Read-side critical sections in interrupt context
* can use just rcu_read_lock().
*
*/
#define rcu_read_lock_bh() local_bh_disable() #define rcu_read_lock_bh() local_bh_disable()
/*
* rcu_read_unlock_bh - marks the end of a softirq-only RCU critical section
*
* See rcu_read_lock_bh() for more information.
*/
#define rcu_read_unlock_bh() local_bh_enable() #define rcu_read_unlock_bh() local_bh_enable()
extern void rcu_init(void); extern void rcu_init(void);
......
...@@ -73,14 +73,15 @@ static DEFINE_PER_CPU(struct tasklet_struct, rcu_tasklet) = {NULL}; ...@@ -73,14 +73,15 @@ static DEFINE_PER_CPU(struct tasklet_struct, rcu_tasklet) = {NULL};
static int maxbatch = 10; static int maxbatch = 10;
/** /**
* call_rcu - Queue an RCU update request. * call_rcu - Queue an RCU callback for invocation after a grace period.
* @head: structure to be used for queueing the RCU updates. * @head: structure to be used for queueing the RCU updates.
* @func: actual update function to be invoked after the grace period * @func: actual update function to be invoked after the grace period
* *
* The update function will be invoked as soon as all CPUs have performed * The update function will be invoked some time after a full grace
* a context switch or been seen in the idle loop or in a user process. * period elapses, in other words after all currently executing RCU
* The read-side of critical section that use call_rcu() for updation must * read-side critical sections have completed. RCU read-side critical
* be protected by rcu_read_lock()/rcu_read_unlock(). * sections are delimited by rcu_read_lock() and rcu_read_unlock(),
* and may be nested.
*/ */
void fastcall call_rcu(struct rcu_head *head, void fastcall call_rcu(struct rcu_head *head,
void (*func)(struct rcu_head *rcu)) void (*func)(struct rcu_head *rcu))
...@@ -98,17 +99,20 @@ void fastcall call_rcu(struct rcu_head *head, ...@@ -98,17 +99,20 @@ void fastcall call_rcu(struct rcu_head *head,
} }
/** /**
* call_rcu_bh - Queue an RCU update request for which softirq handler * call_rcu_bh - Queue an RCU for invocation after a quicker grace period.
* completion is a quiescent state.
* @head: structure to be used for queueing the RCU updates. * @head: structure to be used for queueing the RCU updates.
* @func: actual update function to be invoked after the grace period * @func: actual update function to be invoked after the grace period
* *
* The update function will be invoked as soon as all CPUs have performed * The update function will be invoked some time after a full grace
* a context switch or been seen in the idle loop or in a user process * period elapses, in other words after all currently executing RCU
* or has exited a softirq handler that it may have been executing. * read-side critical sections have completed. call_rcu_bh() assumes
* The read-side of critical section that use call_rcu_bh() for updation must * that the read-side critical sections end on completion of a softirq
* be protected by rcu_read_lock_bh()/rcu_read_unlock_bh() if it is * handler. This means that read-side critical sections in process
* in process context. * 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 fastcall call_rcu_bh(struct rcu_head *head, void fastcall call_rcu_bh(struct rcu_head *head,
void (*func)(struct rcu_head *rcu)) void (*func)(struct rcu_head *rcu))
...@@ -439,8 +443,13 @@ static void wakeme_after_rcu(struct rcu_head *head) ...@@ -439,8 +443,13 @@ static void wakeme_after_rcu(struct rcu_head *head)
} }
/** /**
* synchronize-kernel - wait until all the CPUs have gone * synchronize_kernel - wait until a grace period has elapsed.
* through a "quiescent" state. It may sleep. *
* Control will return to the caller some time after a full grace
* period has elapsed, 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 synchronize_kernel(void) void synchronize_kernel(void)
{ {
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment