lkml.org 
[lkml]   [2018]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] riscv/locking: Strengthen spin_lock() and spin_unlock()
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

\
 
 \ /
  Last update: 2018-02-23 12:16    [W:0.123 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site