lkml.org 
[lkml]   [2006]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [Lse-tech] Re: [ckrm-tech] Re: [PATCH 00/01] Move Exit Connectors
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/
    \
     
     \ /
      Last update: 2006-01-18 03:52    [W:0.038 / U:58.944 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site