On Mon, 11 Mar 2019, Paul Walmsley wrote:

There's been a discussion going on in a private thread about this that I
unfortunately didn't add you to.  The discussion is still ongoing, but I
think Christoph and myself and a few other folks have agreed that the
preempt_disable/enable is not needed for the amoadd approach.  This is
since the apparent intention of the preemption disable/enable is to ensure
the correctness of the counter increment; however there is no risk of
incorrectness in an amoadd sequence since the atomic add is locked across
all of the cache coherency domain.  Christoph, would you disagree with
that characterization?

No. As I said before all write operations have to happen from the local
cpu to a per cpu segment.

There are a few outstanding points that we're trying to talk through, but
it should be fine for an initial implementation to start with the
amoadd-based approach.

As far as the ARM LSE atomic implementation goes, I'm not an expert on
those instructions. If those instructions are locked across all of the
caches for the cores in the Linux system also, then they probably don't
need the preempt_disable/enable either - assuming our collective
understanding of the purpose of the preempt_disable/enable is correct.

All this is, of course, assuming there is no secondary purpose to the
preempt_disable/enable that we haven't managed to elicit yet.

The intention is that the write occurs to the local per cpu segment and
that any per cpu RMW activities (like this_cpu_inc()) appear to be
"atomic" in regards to other processes running on the same cpu.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel