lkml.org 
[lkml]   [2005]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
    Date
    Ingo Molnar <mingo@elte.hu> wrote:
    >
    > * Paul E. McKenney <paulmck@us.ibm.com> wrote:
    >
    >> +#ifdef CONFIG_PREEMPT_RCU
    >> +
    >> +void rcu_read_lock(void)
    >> +{
    >> + if (current->rcu_read_lock_nesting++ == 0) {
    >> + current->rcu_data = &get_cpu_var(rcu_data);
    >> + atomic_inc(&current->rcu_data->active_readers);
    >> + put_cpu_var(rcu_data);
    >>
    >> Need an smp_mb() here for non-x86 CPUs. Otherwise, the CPU can
    >> re-order parts of the critical section to precede the rcu_read_lock().
    >> Could precede the put_cpu_var(), but why increase latency?
    >
    > ok. It's enough to put a barrier into the else branch here, because the
    > atomic op in the main brain is a barrier by itself.

    Since the else branch is only taken when rcu_read_lock_nesting > 0, do
    we need the barrier at all?

    Cheers,
    --
    Visit Openswan at http://www.openswan.org/
    Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
    Home Page: http://gondor.apana.org.au/~herbert/
    PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
    -
    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: 2005-04-06 13:30    [W:2.822 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site