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 17:58:57 +0000	[thread overview]
Message-ID: <0100016935426418-5eaf2d86-8a0f-4c1f-91b7-b4d872d6ba48-000000@email.amazonses.com> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1902280418110.10847@viisi.sifive.com>

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

On Thu, 28 Feb 2019, Paul Walmsley wrote:

> On Fri, 22 Feb 2019, Christopher Lameter wrote:
>
> > On Fri, 22 Feb 2019, Björn Töpel wrote:
> >
> > > > The problem is that the register needs to be referenced by the amo
> > > > instruction. Can amoadd increment an address relative to a scratch
> > > > register?
> > > >
> > >
> > > It cannot. So, we'll end up with (at least) a preempt disabled region...
> >
> > If we need to do that then we already have so much overhead due to that
> > processing that it may not be worthwhile. lc/sc overhead is minor compared
> > to switching preempt on and off I think.
>
> Is it strictly necessary to disable and re-enable preemption?

It is necessary if CONFIG_PREEMPT is set because then the execution can be
interrupted at any time and rescheduled on another hardware thread.

> On a UMA system, it might be preferable to risk the cost of the cache line
> bounce than to flip preemption off and on - assuming there's no other
> impact.

Its not the cost of a cache line bounce. The counter data will be
corrupted since the RMW operations is not properly serialized. The counter
data will be read from one processor, then the execution context may
change and the writeback may occur either to the new execution context
per cpu area (where we overwrite the old value) or to the old exeuction context
per cpu are (where the counter may already have been incremented by other
code that ran in that context)

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

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

  reply	other threads:[~2019-02-28 17:59 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 [this message]
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
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=0100016935426418-5eaf2d86-8a0f-4c1f-91b7-b4d872d6ba48-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).