From: Gary Guo <gary@garyguo.net>
To: Christopher Lameter <cl@linux.com>,
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" <will.deacon@arm.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"Nick Kossifidis" <mick@ics.forth.gr>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: per-cpu thoughts
Date: Tue, 12 Mar 2019 17:59:10 +0000 [thread overview]
Message-ID: <898ae546-fac8-3f5a-e53b-c2941d81ca66@garyguo.net> (raw)
In-Reply-To: <0100016973000e88-99188bf8-0831-4fa4-b3ae-7de6547b651e-000000@email.amazonses.com>
The added instruction would require three operands (base, offset,
value), which is clearly an issue on how to encode it. Also, as RISC-V's
base ISA is already frozen, even if we have this instruction, it will be
an extension, and is not going to be implemented by all hardware. Linux
will still need to support those hardware without this instruction.
On 12/03/2019 17:42, Christopher Lameter wrote:
> On Tue, 12 Mar 2019, Paul Walmsley wrote:
>
>> The counters, though, may not need the preemption disable/reenable.
>> Christoph, you expressed earlier that you think the overhead of the
>> preempt_disable/enable is quite high. Do you think it's worth creating a
>> separate, restricted implementation for per-cpu counters?
>
> As I have always said: I would like to have per cpu atomic instructions
> added on RISCV V that works like those on Intel. Single instruction and
> relative to a per cpu based addressable counter operations please.
>
> I think the attempt to reengineer the core counter mechanisms on Linux is
> not that realistic and would require you to first know the cross platform
> issues that have driven the development of these things in the first
> place. Sorry that I have been just superficially involved in these
> discussions but I have a hard time seeing this going anywere. There are
> already established core implementations and various arches take on this
> issue and those have been around for longer than a decade. It will be hard
> to come up with something better.
>
> Can we focus on the RISC V instruction support? I also do not think that
> this is a currently pressing issue but it will be when you scale up RISC V
> to many cores (especiall hundreds or thousands of concurrent hardware
> threads like what our interest is likely going to be in coming years and
> likely also when RISC V is going to be used for enterprise / cloud data
> services).
>
_______________________________________________
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 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
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 [this message]
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=898ae546-fac8-3f5a-e53b-c2941d81ca66@garyguo.net \
--to=gary@garyguo.net \
--cc=bjorn.topel@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.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).