linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Parri <andrea.parri@amarulasolutions.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Daniel Lustig <dlustig@nvidia.com>,
	Will Deacon <will.deacon@arm.com>,
	Andrea Parri <parri.andrea@gmail.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org, mingo@kernel.org,
	peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com,
	dhowells@redhat.com, Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	akiyks@gmail.com, Palmer Dabbelt <palmer@sifive.com>
Subject: Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
Date: Sat, 8 Sep 2018 11:58:48 +0200	[thread overview]
Message-ID: <20180908095848.GA6272@andrea> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1809071256340.1547-100000@iolanthe.rowland.org>

> Will feels strongly (and Linus agrees) that the LKMM should not require
> ordinary acquire and release to be any stronger than RCpc.
> 
> The issue that Andrea raised has to do with qspinlock, qrwlock, and
> mcs_spinlock, which are implemented using smp_cond_load_acquire()  
> instead of RMW-acquire.  This provides only the ordering properties of
> smp_load_acquire(), namely RCpc, which means that qspinlocks etc. might
> not be RCtso.
> 
> Since we do want locks to be RCtso, the question is how to resolve this 
> discrepancy.

[...]

> To tell the truth, I'm not aware of any code in the kernel that
> actually _needs_ RCtso ordering for locks, but Peter and Will are quite
> firm that it should be required.  Linus would actually like locks to be
> RCsc, but he recognizes that this would incur a noticeable performance
> penalty on Power so he'll settle for RCtso.

It does look like Will, Peter, Linus and me could help you put together
a satisfactory patch description! ;-)  I'm not sure I agree with all
you're claiming/concluding above..., but again: why don't you try to
collect what, in your opinion, are the relevant arguments/comments from
previous reviews of the patch (which, unfortunately, goes back to July)
and then send an updated version?  (I do have the impression that these
discussions would have been much more "easy to follow" if you only did
that time ago/with higher frequency...)

  Andrea

  parent reply	other threads:[~2018-09-08  9:59 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-29 21:10 [PATCH RFC memory-model 0/7] Memory-model changes Paul E. McKenney
2018-08-29 21:10 ` [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire Paul E. McKenney
2018-08-30 12:50   ` Andrea Parri
2018-08-30 21:31     ` Alan Stern
2018-08-31  9:17       ` Andrea Parri
2018-08-31 14:52         ` Alan Stern
2018-08-31 16:06           ` Will Deacon
2018-08-31 18:28             ` Andrea Parri
2018-09-03  9:01               ` Andrea Parri
2018-09-03 17:04                 ` Will Deacon
2018-09-04  8:11                   ` Andrea Parri
2018-09-04 19:09                     ` Alan Stern
2018-09-05  7:21                       ` Andrea Parri
2018-09-05 14:33                         ` Akira Yokosawa
2018-09-05 14:53                           ` Paul E. McKenney
2018-09-05 15:00                           ` Andrea Parri
2018-09-05 15:04                             ` Akira Yokosawa
2018-09-05 15:24                               ` Andrea Parri
2018-09-03 17:52                 ` Alan Stern
2018-09-03 18:28                   ` Andrea Parri
2018-09-06  1:25                 ` Alan Stern
2018-09-06  9:36                   ` Andrea Parri
2018-09-07 16:00                     ` Alan Stern
2018-09-07 16:09                       ` Will Deacon
2018-09-07 16:39                         ` Daniel Lustig
2018-09-07 17:38                           ` Alan Stern
2018-09-08  0:04                             ` Daniel Lustig
2018-09-08  9:58                             ` Andrea Parri [this message]
2018-09-11 19:31                               ` Alan Stern
2018-09-11 20:03                                 ` Paul E. McKenney
2018-09-12 14:24                                   ` Alan Stern
2018-09-13 17:07                                   ` Alan Stern
2018-09-14 14:37                                     ` Andrea Parri
2018-09-14 16:29                                       ` Alan Stern
2018-09-14 19:44                                         ` Andrea Parri
2018-09-14 21:08                                       ` [PATCH v5] " Alan Stern
2018-09-15  3:56                                         ` Paul E. McKenney
2018-09-03 17:05               ` [PATCH RFC LKMM 1/7] " Will Deacon
2018-08-31 17:55           ` Andrea Parri
2018-08-29 21:10 ` [PATCH RFC LKMM 2/7] doc: Replace smp_cond_acquire() with smp_cond_load_acquire() Paul E. McKenney
2018-09-14 16:59   ` Will Deacon
2018-09-14 18:20     ` Paul E. McKenney
2018-08-29 21:10 ` [PATCH RFC LKMM 3/7] EXP tools/memory-model: Add more LKMM limitations Paul E. McKenney
2018-08-30  9:17   ` Andrea Parri
2018-08-30 22:18     ` Paul E. McKenney
2018-08-31  9:43       ` Andrea Parri
2018-09-06 18:34         ` Paul E. McKenney
2018-08-29 21:10 ` [PATCH RFC LKMM 4/7] tools/memory-model: Fix a README typo Paul E. McKenney
2018-08-29 21:10 ` [PATCH RFC LKMM 5/7] EXP tools/memory-model: Add scripts to check github litmus tests Paul E. McKenney
2018-08-29 21:10 ` [PATCH RFC LKMM 6/7] EXP tools/memory-model: Make scripts take "-j" abbreviation for "--jobs" Paul E. McKenney
2018-08-29 21:10 ` [PATCH RFC LKMM 7/7] EXP tools/memory-model: Add .cfg and .cat files for s390 Paul E. McKenney
2018-08-31 16:06   ` Will Deacon
2018-09-01 17:08     ` Paul E. McKenney
2018-09-14 16:36 ` [PATCH RFC memory-model 0/7] Memory-model changes Paul E. McKenney
2018-09-14 17:19   ` Alan Stern
2018-09-14 18:29     ` Paul E. McKenney

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