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: "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 17:42:57 +0000	[thread overview]
Message-ID: <0100016973000e88-99188bf8-0831-4fa4-b3ae-7de6547b651e-000000@email.amazonses.com> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1903120717110.26459@viisi.sifive.com>

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

  reply	other threads:[~2019-03-12 17:43 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 [this message]
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=0100016973000e88-99188bf8-0831-4fa4-b3ae-7de6547b651e-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).