linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Parri <parri.andrea@gmail.com>
To: Daniel Lustig <dlustig@nvidia.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org, Palmer Dabbelt <palmer@sifive.com>,
	Albert Ou <albert@sifive.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Will Deacon <will.deacon@arm.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	David Howells <dhowells@redhat.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	Akira Yokosawa <akiyks@gmail.com>, Ingo Molnar <mingo@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-riscv@lists.infradead.org
Subject: Re: [RFC PATCH] riscv/locking: Strengthen spin_lock() and spin_unlock()
Date: Fri, 23 Feb 2018 12:16:01 +0100	[thread overview]
Message-ID: <20180223111601.GA449@andrea> (raw)
In-Reply-To: <563431d0-4fb5-9efd-c393-83cc5197e934@nvidia.com>

On Thu, Feb 22, 2018 at 11:47:57AM -0800, Daniel Lustig wrote:
> On 2/22/2018 10:27 AM, Peter Zijlstra wrote:
> > On Thu, Feb 22, 2018 at 10:13:17AM -0800, Paul E. McKenney wrote:
> >> So we have something that is not all that rare in the Linux kernel
> >> community, namely two conflicting more-or-less concurrent changes.
> >> This clearly needs to be resolved, either by us not strengthening the
> >> Linux-kernel memory model in the way we were planning to or by you
> >> strengthening RISC-V to be no weaker than PowerPC for these sorts of
> >> externally viewed release-acquire situations.
> >>
> >> Other thoughts?
> > 
> > Like said in the other email, I would _much_ prefer to not go weaker
> > than PPC, I find that PPC is already painfully weak at times.
> 
> Sure, and RISC-V could make this work too by using RCsc instructions
> and/or by using lightweight fences instead.  It just wasn't clear at
> first whether smp_load_acquire() and smp_store_release() were RCpc,
> RCsc, or something else, and hence whether RISC-V would actually need
> to use something stronger than pure RCpc there.  Likewise for
> spin_unlock()/spin_lock() and everywhere else this comes up.

Thank you for the confirmations.

The hope was indeed that this thread helped clarify what the (current)
LKMM "expectations" are, and how these are likely to evolve in a near
future.  And Yes, I'm definitely with you and Paul on "let us (try to)
keep LKMM and RISC-V synchronized"! ;-)

  Andrea


> 
> 
> Dan

  reply	other threads:[~2018-02-23 11:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-22 12:19 [RFC PATCH] riscv/locking: Strengthen spin_lock() and spin_unlock() Andrea Parri
2018-02-22 12:44 ` Andrea Parri
2018-02-22 13:40 ` Peter Zijlstra
2018-02-22 14:12   ` Andrea Parri
2018-02-22 17:27     ` Daniel Lustig
2018-02-22 18:13       ` Paul E. McKenney
2018-02-22 18:27         ` Peter Zijlstra
2018-02-22 19:47           ` Daniel Lustig
2018-02-23 11:16             ` Andrea Parri [this message]
2018-02-26 10:39             ` Will Deacon
2018-02-26 14:21             ` Luc Maranget
2018-02-26 16:06               ` Linus Torvalds
2018-02-26 16:24                 ` Will Deacon
2018-02-26 17:00                   ` Linus Torvalds
2018-02-26 17:10                     ` Will Deacon
2018-03-06 13:00                     ` Peter Zijlstra
2018-02-27  5:06                   ` Boqun Feng
2018-02-27 10:16                     ` Boqun Feng
2018-03-01 15:11             ` Andrea Parri
2018-03-01 21:54               ` Palmer Dabbelt
2018-03-01 22:21                 ` Daniel Lustig
2018-02-22 20:02           ` Paul E. McKenney
2018-02-22 18:21       ` Peter Zijlstra

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=20180223111601.GA449@andrea \
    --to=parri.andrea@gmail.com \
    --cc=akiyks@gmail.com \
    --cc=albert@sifive.com \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=luc.maranget@inria.fr \
    --cc=mingo@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=palmer@sifive.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@linux-foundation.org \
    --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).