* Paul E. McKenney | 2015-04-24 13:13:40 [-0700]:
>Hmmm... allyesconfig would have PROVE_RCU=y, which would mean that the
>above two would contain lockdep calls that might in some cases defeat
>inlining. With the more typical production choice of PROVE_RCU=n, I would
>expect these to just be a call instruction, which should get inlined.
Ok, here are the results:
with PROVE_RCU=y:
rcu_read_lock: 383 duplicates
with PROVE_RCU=n:
rcu_read_lock: 114 duplicates
If you look at the function anatomy of rcu_read_lock you often see the
following definitions:
<rcu_read_lock>:
55 push %rbp
48 89 e5 mov %rsp,%rbp
48 c7 c7 50 64 e7 85 mov $0xffffffff85e76450,%rdi
e8 ce ff ff ff callq ffffffff816af206 <rcu_lock_acquire>
5d pop %rbp
c3 retq
but sometimes rcu_read_lock looks:
<rcu_read_lock>:
55 push %rbp
48 89 e5 mov %rsp,%rbp
50 push %rax
68 83 1e 1c 81 pushq $0xffffffff811c1e83
b9 02 00 00 00 mov $0x2,%ecx
31 d2 xor %edx,%edx
45 31 c9 xor %r9d,%r9d
45 31 c0 xor %r8d,%r8d
31 f6 xor %esi,%esi
48 c7 c7 50 64 e7 85 mov $0xffffffff85e76450,%rdi
e8 86 4c f9 ff callq ffffffff81156b2e <lock_acquire>
5a pop %rdx
59 pop %rcx
c9 leaveq
c3 retq
Means rcu_lock_acquire() is inlined here - but not in every compilation unit.
Don't know exactly what forces gcc to inline not everywhere. Maybe register
pressure in the function unit, or at least gcc is think that. I don't know.
At the end you may notice that gcc inlining decisions are not always perfect
and a little bit fuzzy (sure, they have their metric/scoring system). And
sometimes the inlining should be enforced - as this patch do for some important
functions. But as I said we should not enforce it everywhere, rather we should
pray for better heuristics and let the compiler choose the best strategy (and
incorporate -Os/-O2 decisions too). I think this is the best compromise here.
Cheers, Hagen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
