mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
To: Alan Stern <stern@rowland.harvard.edu>,
	Hernan Ponce de Leon <hernan.poncedeleon@huaweicloud.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	kernel-team@meta.com, parri.andrea@gmail.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: Thu, 16 May 2024 10:31:26 +0200	[thread overview]
Message-ID: <e030f7a4-97e7-4e91-bbae-230ee5c97763@huaweicloud.com> (raw)
In-Reply-To: <72c804c8-2511-4349-a823-bc1de8bb729e@rowland.harvard.edu>



Am 5/16/2024 um 3:43 AM schrieb Alan Stern:
> Hernan and Jonas:
> 
> Can you explain more fully the changes you want to make to herd7 and/or
> the LKMM?  The goal is to make the memory barriers currently implicit in
> RMW operations explicit, but I couldn't understand how you propose to do
> this.
> 
> Are you going to change herd7 somehow, and if so, how?  It seems like
> you should want to provide sufficient information so that the .bell
> and .cat files can implement the appropriate memory barriers associated
> with each RMW operation.  What additional information is needed?  And
> how (explained in English, not by quoting source code) will the .bell
> and .cat files make use of this information?
> 
> Alan


I don't know whether herd7 needs to be changed. Probably, herd7 does the 
following:
- if a tag called Mb appears on an rmw instruction (by instruction I 
mean things like xchg(), atomic_inc_return_relaxed()), replace it with 
one of those things:
   * full mb ; once (the rmw) ; full mb, if a value returning 
(successful) rmw
   * once (the rmw)   otherwise
- everything else gets translated 1:1 into some internal representation

What I'm proposing is:
1. remove this transpilation step,
2. and instead allow the Mb tag to actually appear on RMW instructions
3. change the cat file to explicitly define the behavior of the Mb tag 
on RMW instructions

There are probably two ways to achieve this:
a) change herd7 to remove the special behavior for Mb, after that we 
should be able to do everything else in the .cat/.bell/.def files.
b) sidestep herd7's behavior by renaming Mb to _Mb in the .def file,
  and then defining Mb=_Mb in the .bell file, and define the semantics 
of the Mb tag in the .cat files.


The latter would not include modification to herd7, but it's a bit hacky.

I'm not sure if the second way really works since I don't know exactly 
how the herd7 tool does the transpilation,  e.g., if it really looks for 
an Mb tag or rather for the names of the instructions.

Does it make sense?

jonas


  reply	other threads:[~2024-05-16  8:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-16  1:43 Alan Stern
2024-05-16  8:31 ` Jonas Oberhauser [this message]
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
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=e030f7a4-97e7-4e91-bbae-230ee5c97763@huaweicloud.com \
    --to=jonas.oberhauser@huaweicloud.com \
    --cc=boqun.feng@gmail.com \
    --cc=hernan.poncedeleon@huaweicloud.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=joel@joelfernandes.org \
    --cc=kernel-team@meta.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=parri.andrea@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®