All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Parri <parri.andrea@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>,
	Hernan Ponce de Leon <hernan.poncedeleon@huaweicloud.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	kernel-team@meta.com, boqun.feng@gmail.com, j.alglave@ucl.ac.uk,
	luc.maranget@inria.fr, Joel Fernandes <joel@joelfernandes.org>
Subject: Re: LKMM: Making RMW barriers explicit
Date: Wed, 22 May 2024 18:54:25 +0200	[thread overview]
Message-ID: <Zk4jQe7Vq3N2Vip0@andrea> (raw)
In-Reply-To: <6174fd09-b287-49ae-b117-c3a36ef3800a@rowland.harvard.edu>

Alan, all,

("randomly" picking a recent post in the thread, after having observed
this discussion for a while...)

> It would be better if there was a way to tell herd7 not to add the 'mb 
> tag to failed instructions in the first place.  This approach is 
> brittle; see below.

AFAIU, changing the herd representation to generate mb-accesses in place
of certain mb-fences...

> If you do want to use this approach, it should be simplified.  All you 
> need is:
> 
> 	[M] ; po ; [RMW_MB]
> 
> 	[RMW_MB] ; po ; [M]
> 
> This is because events tagged with RMW_MB always are memory accesses, 
> and accesses that aren't part of the RMW are already covered by the 
> fencerel(Mb) thing above.

... and updating the .cat file to the effects of something like

  -let mb = ([M] ; fencerel(Mb) ; [M]) |
  +let mb = (([M] ; po? ; [Mb] ; po? ; [M]) \ id) |

... can hardly be called "making RMW barriers explicit".  (So much so
that the first commit in PR #865 was titled "Remove explicit barriers
from RMWs".  :-))

Overall, this discussion rather seems to confirm the close link between
tools/memory-model/ and herdtools7.  (After all, to what extent could
any putative RMW_MB be considered "explicit" without _knowing the under-
lying representation of the RMW operations...)  My understanding is that
this discussion was at least in part motivated by a desire to experiment
and familiarize with the current herd representation (that does indeed
require some getting-used-to...); this suggests, as some of you already
mentioned, to add some comments or a .txt in tools/memory-model/ in order
to document such representation and ameliorate that experience.  OTOH, I
must admit, I'm unable to see here sufficient motivation(tm) for changing
the current representation (and model): not the how, but the why...

  Andrea

  reply	other threads:[~2024-05-22 16:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-16  1:43 LKMM: Making RMW barriers explicit Alan Stern
2024-05-16  8:31 ` Jonas Oberhauser
2024-05-16  8:44   ` Hernan Ponce de Leon
2024-05-18  0:31     ` Alan Stern
2024-05-21  9:57       ` Jonas Oberhauser
2024-05-21 15:36         ` Alan Stern
2024-05-22  9:20           ` Jonas Oberhauser
2024-05-22 14:20             ` Alan Stern
2024-05-22 16:54               ` Andrea Parri [this message]
2024-05-22 18:20                 ` Alan Stern
2024-05-22 19:48                   ` Hernan Ponce de Leon
2024-05-23  9:04                     ` Andrea Parri
2024-05-23 14:27                 ` Jonas Oberhauser
2024-05-23 16:35                   ` Andrea Parri
2024-05-23 20:30                     ` Jonas Oberhauser
2024-05-24  3:30                       ` Andrea Parri
2024-05-24  8:16                       ` Hernan Ponce de Leon
2024-05-23 12:54               ` Jonas Oberhauser
2024-05-23 13:35                 ` Paul E. McKenney
2024-05-23 14:05                 ` Alan Stern
2024-05-23 14:26                   ` Hernan Ponce de Leon
2024-05-23 15:14                     ` Boqun Feng
2024-05-24  1:38                       ` Alan Stern
2024-05-24  2:50                         ` Boqun Feng
2024-05-24 14:14                           ` Alan Stern
2024-05-24 14:34                             ` Boqun Feng
2024-05-24 14:53                               ` Alan Stern
2024-05-24 18:09                                 ` Jonas Oberhauser
2024-05-24 18:47                                   ` Boqun Feng
2024-05-24 18:48                                   ` Alan Stern
2024-05-23 16:05                     ` Alan Stern
2024-05-23 14:36                   ` Jonas Oberhauser
2024-05-21 11:38       ` Hernan Ponce de Leon

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=Zk4jQe7Vq3N2Vip0@andrea \
    --to=parri.andrea@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=hernan.poncedeleon@huaweicloud.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=joel@joelfernandes.org \
    --cc=jonas.oberhauser@huaweicloud.com \
    --cc=kernel-team@meta.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=paulmck@kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.