linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christopher Lameter <cl@linux.com>
To: Paul Walmsley <paul.walmsley@sifive.com>
Cc: "Nick Kossifidis" <mick@ics.forth.gr>,
	"Björn Töpel" <bjorn.topel@gmail.com>,
	"Paul Walmsley" <paul@pwsan.com>,
	"Palmer Dabbelt" <palmer@sifive.com>,
	linux-riscv@lists.infradead.org
Subject: Re: per-cpu thoughts
Date: Thu, 28 Feb 2019 19:09:38 +0000	[thread overview]
Message-ID: <0100016935831a0a-8ad31ea0-9ab5-44e7-8aae-ac8cb2491c72-000000@email.amazonses.com> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1902281034390.10196@viisi.sifive.com>

On Thu, 28 Feb 2019, Paul Walmsley wrote:

> This is the AMO-based sequence that Palmer wrote in his E-mail:
>
>    li t0, 1
>    la t1, counter
>    amoadd.w zero, t0, 0(t1)
>
> The RMW takes place in the amoadd, and executes atomically from the point
> of view of all cores in the cache coherency domain.
>
> Or am I misunderstanding you?

Yes Palmers example missed having the address of the per cpu space
somewhere in a register (lets call it "tPerCpu"). Then you can do

	li t0, 1
	la t1, offset of counter in percpu area
	amoadd.w zero,t0, 0(t1 + tPerCpu)

But as far as we know we do not have an amoadd that can do this. If you
add the percpu space address earlier:

	li t0, 1
	la t1, offset of counter in percpu area
	add t1, t1, tPerCPu
	amoadd.w zero, t0, 0(t1)

then you have the dnager of the amoadd being done on the wrong per cpu
address because the scheduler may move the execution thread to a different
processor betweeen the "add" and the amoadd.

If you do it without the amoadd with just lc/sc then there more potential
issues exist.


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

  reply	other threads:[~2019-02-28 19:09 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 [this message]
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
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=0100016935831a0a-8ad31ea0-9ab5-44e7-8aae-ac8cb2491c72-000000@email.amazonses.com \
    --to=cl@linux.com \
    --cc=bjorn.topel@gmail.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mick@ics.forth.gr \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paul@pwsan.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).