From: Christopher Lameter <cl@linux.com>
To: Paul Walmsley <paul.walmsley@sifive.com>
Cc: "Paul Walmsley" <paul@pwsan.com>,
"Björn Töpel" <bjorn.topel@gmail.com>,
"Palmer Dabbelt" <palmer@sifive.com>,
will.deacon@arm.com, catalin.marinas@arm.com,
"Nick Kossifidis" <mick@ics.forth.gr>,
linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: per-cpu thoughts
Date: Tue, 12 Mar 2019 04:26:15 +0000 [thread overview]
Message-ID: <010001697026a740-ffe901ce-8e6a-445b-883f-068dd289b0a2-000000@email.amazonses.com> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1903110814130.11892@viisi.sifive.com>
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-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2019-03-12 4:26 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 19:57 per-cpu thoughts Björn Töpel
2019-02-21 15:57 ` Christopher Lameter
2019-02-21 16:28 ` Paul Walmsley
2019-02-21 17:24 ` Björn Töpel
2019-02-21 17:49 ` Paul Walmsley
2019-02-21 19:40 ` Palmer Dabbelt
2019-02-22 15:04 ` Christopher Lameter
2019-02-22 15:36 ` Nick Kossifidis
2019-02-22 15:56 ` Christopher Lameter
2019-02-22 19:47 ` Björn Töpel
2019-02-22 19:56 ` Christopher Lameter
2019-02-28 12:20 ` Paul Walmsley
2019-02-28 17:58 ` Christopher Lameter
2019-02-28 18:42 ` Paul Walmsley
2019-02-28 19:09 ` Christopher Lameter
2019-02-28 20:21 ` Paul Walmsley
2019-03-01 1:13 ` Christopher Lameter
2019-03-08 7:17 ` Björn Töpel
2019-03-11 13:22 ` Palmer Dabbelt
2019-03-11 14:48 ` Björn Töpel
2019-03-11 14:56 ` Christopher Lameter
2019-03-11 15:05 ` Björn Töpel
2019-03-11 15:26 ` Paul Walmsley
2019-03-11 16:48 ` Mark Rutland
2019-03-11 18:39 ` Paul Walmsley
2019-03-12 11:23 ` Mark Rutland
2019-03-12 16:01 ` Paul Walmsley
2019-03-12 17:34 ` Christopher Lameter
2019-03-12 4:26 ` Christopher Lameter [this message]
2019-03-12 14:21 ` Paul Walmsley
2019-03-12 17:42 ` Christopher Lameter
2019-03-12 17:59 ` Gary Guo
2019-03-13 18:58 ` Christopher Lameter
2019-03-13 20:15 ` Paul Walmsley
2019-03-22 14:51 ` Nick Kossifidis
2019-03-22 17:57 ` Christopher Lameter
2019-03-11 15:51 ` Christopher Lameter
2019-03-11 16:35 ` Björn Töpel
2019-03-12 4:22 ` Christopher Lameter
2019-02-22 19:48 ` Björn Töpel
2019-02-22 20:53 ` Nick Kossifidis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=010001697026a740-ffe901ce-8e6a-445b-883f-068dd289b0a2-000000@email.amazonses.com \
--to=cl@linux.com \
--cc=bjorn.topel@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mick@ics.forth.gr \
--cc=palmer@sifive.com \
--cc=paul.walmsley@sifive.com \
--cc=paul@pwsan.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).