Re: [tip:perf/core] tools/perf: Add required memory barriers
From: Vince Weaver
Date: Wed Nov 06 2013 - 12:29:58 EST
On Wed, 6 Nov 2013, Peter Zijlstra wrote:
> On Wed, Nov 06, 2013 at 03:44:56PM +0100, Peter Zijlstra wrote:
> > long head = ((__atomic long)pc->data_head).load(memory_order_acquire);
> > coupled with:
> > ((__atomic long)pc->data_tail).store(tail, memory_order_release);
> > might be the 'right' and proper C11 incantations to avoid having to
> > touch kernel macros; but would obviously require a recent compiler.
> > Barring that, I think we're stuck with:
> > long head = ACCESS_ONCE(pc->data_head);
> > smp_rmb();
> > ...
> > smp_mb();
> > pc->data_tail = tail;
> > And using the right asm goo for the barriers. That said, all these asm
> > barriers should include a compiler barriers (memory clobber) which
> > _should_ avoid the worst compiler trickery -- although I don't think it
> > completely obviates the need for ACCESS_ONCE() -- uncertain there.
> There's one for icc on x86.
I think the problem here is this really isn't a good interface.
Most users just want the most recent batch of samples. Something like
where perf_read_sample_buffer() is a syscall that just copies the current
valid samples to userspace.
Yes, this is inefficient (requires an extra copy of the values) but the
kernel then could handle all the SMP/multithread/barrier/locking issues.
How much overhead is really introduced by making a copy?
Requiring the user of a kernel interface to have a deep knowledge of
optimizing compilers, barriers, and CPU memory models is just asking for
Especially as this all needs to get documented in the manpage and I'm not
sure that's possible in a sane fashion.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/