* Will Deacon <will.dea...@arm.com> wrote:
> On Tue, Feb 02, 2016 at 10:06:36AM -0800, Linus Torvalds wrote:
> > On Tue, Feb 2, 2016 at 9:51 AM, Will Deacon <will.dea...@arm.com> wrote:
> > >
> > > Given that the vast majority of weakly ordered architectures respect
> > > address dependencies, I would expect all of them to be hurt if they
> > > were forced to use barrier instructions instead, even those where the
> > > microarchitecture is fairly strongly ordered in practice.
> >
> > I do wonder if it would be all that noticeable, though. I don't think
> > we've really had benchmarks.
> >
> > For example, most of the RCU list traversal shows up on x86 - where
> > loads are already acquires. But they show up not because of that, but
> > because a RCU list traversal is pretty much always going to take the
> > cache miss.
> >
> > So it would actually be interesting to just try it - what happens to
> > kernel-centric benchmarks (which are already fairly rare) on arm if we
> > change the rcu_dereference() to be a smp_load_acquire()?
> >
> > Because maybe nothing happens at all. I don't think we've ever tried it.
>
> FWIW, and this is by no means conclusive, I hacked that up quickly and ran
> hackbench a few times on the nearest idle arm64 system. The results were
> consistently ~4% slower using acquire for rcu_dereference.
Could you please double check that? The thing is that hackbench is a
_notoriously_
unstable workload and very dependent on various small details such as kernel
image
layout and random per-bootup cache/memory layouts details.
In fact I'd suggest to test this via a quick runtime hack like this in
rcupdate.h:
extern int panic_timeout;
...
if (panic_timeout)
smp_load_acquire(p);
else
typeof(*p) *________p1 = (typeof(*p)
*__force)lockless_dereference(p);
(or so)
and then you can start a loop of hackbench runs, and in another terminal change
the ordering primitive via:
echo 1 > /proc/sys/kernel/panic # smpload_acquire()
echo 0 > /proc/sys/kernel/panic # smp_read_barrier_depends()
without having to reboot the kernel.
Also, instead of using hackbench which has a too short runtime that makes it
sensitive to scheduling micro-details, you could try the perf-bench hackbench
work-alike where the number of loops is parametric:
triton:~/tip> perf bench sched messaging -l 10000
# Running 'sched/messaging' benchmark:
# 20 sender and receiver processes per group
# 10 groups == 400 processes run
Total time: 4.532 [sec]
and you could get specific numbers of noise estimations via:
triton:~/tip> perf stat --null --repeat 10 perf bench sched messaging -l 10000
[...]
Performance counter stats for 'perf bench sched messaging -l 10000' (10 runs):
4.616404309 seconds time elapsed
( +- 1.67% )
note that even with a repeat count of 10 runs and a loop count 100 times larger
than the hackbench default, the intrinsic noise of this workload was still 1.6%
-
and that does not include boot-to-boot systematic noise.
It's very easy to get systemic noise with hackbench workloads and go down the
entirely wrong road.
Of course, the numbers might also confirm your 4% figure!
Thanks,
Ingo
