Re: [patch 01/15] Kernel Tracepoints

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Peter Zijlstra <peterz@...>
Cc: <akpm@...>, Ingo Molnar <mingo@...>, <linux-kernel@...>, Masami Hiramatsu <mhiramat@...>, Frank Ch. Eigler <fche@...>, Hideo AOKI <haoki@...>, Takashi Nishiie <t-nishiie@...>, Steven Rostedt <rostedt@...>, Alexander Viro <viro@...>, Eduard - Gabriel Munteanu <eduard.munteanu@...>, Paul E McKenney <paulmck@...>
Date: Tuesday, July 15, 2008 - 11:22 am

* Peter Zijlstra (peterz@infradead.org) wrote:

Exactly. I used the implementation of rcu_assign_pointer as a hint that
we did not need barriers when setting the pointer to NULL, and thus we
should not need the read barrier when reading the NULL pointer, because
it references no data.

#define rcu_assign_pointer(p, v) \
        ({ \
                if (!__builtin_constant_p(v) || \
                    ((v) != NULL)) \
                        smp_wmb(); \
                (p) = (v); \
        })

#define rcu_dereference(p)     ({ \
                                typeof(p) _________p1 = ACCESS_ONCE(p); \
                                smp_read_barrier_depends(); \
                                (_________p1); \
                                })

But I think you are right, since we are already in unlikely code, using
rcu_dereference as you do is better than my use of read barrier depends.
It should not change anything in the assembly result except on alpha,
where the read_barrier_depends() is not a nop.

I wonder if there would be a way to add this kind of NULL pointer case
check without overhead in rcu_dereference() on alpha. I guess not, since
the pointer is almost never known at compile-time. And I guess Paul must
already have thought about it. The only case where we could add this
test is when we know that we have a if (ptr != NULL) test following the
rcu_dereference(); we could then assume the compiler will merge the two
branches since they depend on the same condition.


On x86_64 :

 820:   bf 01 00 00 00          mov    $0x1,%edi
 825:   e8 00 00 00 00          callq  82a <thread_return+0x136>
 82a:   48 8b 1d 00 00 00 00    mov    0x0(%rip),%rbx        # 831 <thread_return+0x13d>
 831:   48 85 db                test   %rbx,%rbx
 834:   75 21                   jne    857 <thread_return+0x163>
 836:   eb 27                   jmp    85f <thread_return+0x16b>
 838:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
 83f:   00 
 840:   48 8b 95 68 ff ff ff    mov    -0x98(%rbp),%rdx
 847:   48 8b b5 60 ff ff ff    mov    -0xa0(%rbp),%rsi
 84e:   4c 89 e7                mov    %r12,%rdi
 851:   48 83 c3 08             add    $0x8,%rbx
 855:   ff d0                   callq  *%rax
 857:   48 8b 03                mov    (%rbx),%rax
 85a:   48 85 c0                test   %rax,%rax
 85d:   75 e1                   jne    840 <thread_return+0x14c>
 85f:   bf 01 00 00 00          mov    $0x1,%edi
 864:

for 68 bytes.

My original implementation was 77 bytes, so yes, we have a win.

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Wed Jul 9, 10:59 am)
Re: [patch 01/15] Kernel Tracepoints, Peter Zijlstra, (Tue Jul 15, 3:50 am)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 9:25 am)
Re: [patch 01/15] Kernel Tracepoints, Peter Zijlstra, (Tue Jul 15, 10:03 am)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 3:02 pm)
Re: [patch 01/15] Kernel Tracepoints, Peter Zijlstra, (Tue Jul 15, 3:52 pm)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 10:46 am)
Re: [patch 01/15] Kernel Tracepoints, Peter Zijlstra, (Tue Jul 15, 11:13 am)
Re: [patch 01/15] Kernel Tracepoints, Masami Hiramatsu, (Tue Jul 15, 2:52 pm)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 3:08 pm)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 2:22 pm)
Re: [patch 01/15] Kernel Tracepoints, Steven Rostedt, (Tue Jul 15, 2:33 pm)
Re: [patch 01/15] Kernel Tracepoints, Peter Zijlstra, (Tue Jul 15, 9:59 am)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 10:27 am)
Re: [patch 01/15] Kernel Tracepoints, Peter Zijlstra, (Tue Jul 15, 10:42 am)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 11:22 am)
Re: [patch 01/15] Kernel Tracepoints, Peter Zijlstra, (Tue Jul 15, 11:31 am)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 1:50 pm)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 12:08 pm)
Re: [patch 01/15] Kernel Tracepoints, Paul E. McKenney, (Fri Aug 1, 5:10 pm)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 12:26 pm)
Re: [patch 01/15] Kernel Tracepoints, Peter Zijlstra, (Tue Jul 15, 12:25 pm)
Re: [patch 01/15] Kernel Tracepoints, Paul E. McKenney, (Fri Aug 1, 5:10 pm)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 12:51 pm)
Re: [patch 01/15] Kernel Tracepoints, Paul E. McKenney, (Fri Aug 1, 5:10 pm)
Re: [patch 01/15] Kernel Tracepoints, Peter Zijlstra, (Fri Aug 1, 8:03 pm)
Re: [patch 01/15] Kernel Tracepoints, Paul E. McKenney, (Fri Aug 1, 8:17 pm)
Re: [patch 01/15] Kernel Tracepoints, Mathieu Desnoyers, (Tue Jul 15, 11:50 am)
Re: [patch 01/15] Kernel Tracepoints, Paul E. McKenney, (Fri Aug 1, 5:10 pm)