[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131106151055.GQ10651@twins.programming.kicks-ass.net>
Date: Wed, 6 Nov 2013 16:10:55 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Vince Weaver <vince@...ter.net>
Cc: mingo@...nel.org, hpa@...or.com, anton@...ba.org,
mathieu.desnoyers@...ymtl.ca, linux-kernel@...r.kernel.org,
michael@...erman.id.au, paulmck@...ux.vnet.ibm.com,
benh@...nel.crashing.org, fweisbec@...il.com, VICTORK@...ibm.com,
tglx@...utronix.de, oleg@...hat.com, mikey@...ling.org,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perf/core] tools/perf: Add required memory barriers
On Wed, Nov 06, 2013 at 09:55:17AM -0500, Vince Weaver wrote:
> Having perf in the kernel tree really makes it hard for you guys to keep a
> clean API/ABI it seems.
Lock free buffers are 'fun'.. The ABI can be described as:
read pc->data_head
// ensure no other reads get before this point and ->data_head
// doesn't get re-read hereafter.
read data; using pc->data_tail, until the read head value.
// ensure all reads are completed before issuing
write pc->data_tail
How you want to implement that on your compiler/arch combination is up
to you. Like said, C11 has the __atomic bits you can use to implement
this in proper C; barring that, you'll have to get creative and use
assembly one way or another.
On x86/sparc/s390 which have relatively strong memory models its fairly
easy, on powerpc/arm which have much weaker models its more fun.
This isn't actually something that has changed; its just that we
recently found some implementations thereof were buggy.
We provide an implementation in GNU C, if you want to use something else
you get to deal with that other compiler.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists