On Wed, Jan 18, 2006 at 10:57:47AM +1100, Keith Owens wrote:
> "Paul E. McKenney" (on Tue, 17 Jan 2006 09:26:17 -0800) wrote:
[ . . .]
> >One other thing -- given that you are requiring that the read side
> >have preemption disabled, another update-side option would be to
> >use synchronize_sched() to wait for all preemption-disabled code
> >segments to complete. This would allow you to remove the per-CPU
> >reference counters from the read side, but would require that the
> >update side either (1) be able to block or (2) be able to defer
> >the cleanup to process context.
>
> Originally I looked at that code but the comment scared me off.
> synchronize_sched() maps to synchronize_rcu() and the comment says that
> this only protects against rcu_read_lock(), not against preempt_disable().
Good point -- in mainline kernels (but not in some realtime
variants), the two guarantees happen to be one and the same.
But the comment certainly does not make this clear.
> /**
> * synchronize_sched - block until all CPUs have exited any non-preemptive
> * kernel code sequences.
> *
> * This means that all preempt_disable code sequences, including NMI and
> * hardware-interrupt handlers, in progress on entry will have completed
> * before this primitive returns. However, this does not guarantee that
> * softirq handlers will have completed, since in some kernels
> *
> * This primitive provides the guarantees made by the (deprecated)
> * synchronize_kernel() API. In contrast, synchronize_rcu() only
> * guarantees that rcu_read_lock() sections will have completed.
> */
> #define synchronize_sched() synchronize_rcu()
Does the following change help?
Thanx, Paul
diff -urpNa -X dontdiff linux-2.6.15/include/linux/rcupdate.h linux-2.6.15-RCUcomment/include/linux/rcupdate.h
--- linux-2.6.15/include/linux/rcupdate.h 2006-01-02 19:21:10.000000000 -0800
+++ linux-2.6.15-RCUcomment/include/linux/rcupdate.h 2006-01-17 18:48:33.000000000 -0800
@@ -265,11 +265,14 @@ static inline int rcu_pending(int cpu)
* This means that all preempt_disable code sequences, including NMI and
* hardware-interrupt handlers, in progress on entry will have completed
* before this primitive returns. However, this does not guarantee that
- * softirq handlers will have completed, since in some kernels
+ * softirq handlers will have completed, since in some kernels, these
+ * handlers can run in process context, and can block.
*
* This primitive provides the guarantees made by the (deprecated)
* synchronize_kernel() API. In contrast, synchronize_rcu() only
* guarantees that rcu_read_lock() sections will have completed.
+ * In "classic RCU", these two guarantees happen to be one and
+ * the same, but can differ in realtime RCU implementations.
*/
#define synchronize_sched() synchronize_rcu()
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
