Re: [GIT PULL tools] Linux kernel memory model

From: Ingo Molnar
Date: Wed Jan 31 2018 - 04:00:18 EST



* Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> wrote:

> On Mon, Jan 29, 2018 at 07:57:24AM +0100, Ingo Molnar wrote:
> >
> > hi Paul,
> >
> > * Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > > Hello, Ingo,
> > >
> > > This pull request contains a single commit that adds a memory model to
> > > the tools directory. This memory model can (roughly speaking) be thought
> > > of as an automated version of memory-barriers.txt. It is written in the
> > > "cat" language, which is executable by the externally provided "herd7"
> > > simulator, which exhaustively explores the state space of small litmus
> > > tests.
> > >
> > > This memory model is accompanied by extensive documentation on its use
> > > and its design. Two versions have been sent to LKML and feedback
> > > incorporated:
> > >
> > > 1. http://lkml.kernel.org/r/20171113184031.GA26302@xxxxxxxxxxxxxxxxxx
> > > 2. http://lkml.kernel.org/r/20180119035855.GA29296@xxxxxxxxxxxxxxxxxx
> > >
> > > This model has been presented and demoed at a number of Linux gatherings,
> > > including the 2016 LinuxCon EU, the 2016 Linux Plumbers Conference,
> > > the 2016 Linux Kernel Summit, the 2017 linux.conf.au, and the 2017 Linux
> > > Plumbers Conference, which featured a workshop helping a number of Linux
> > > kernel hackers install and use the tool.
> > >
> > > This memory model has matured to the point where it would be good to include
> > > it in the Linux kernel, for example, to allow it to track changes as new
> > > hardware and use cases are added. We expect the rate of change to be similar
> > > to that of Documentation/memory-barriers.txt.
> > >
> > > This memory model is available in the git repository at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> > >
> > > for you to fetch changes up to 1c27b644c0fdbc61e113b8faee14baeb8df32486:
> > >
> > > Automate memory-barriers.txt; provide Linux-kernel memory model (2018-01-24 20:53:49 -0800)
> >
> > Looks good to me, but the commit is not in the master branch of your tree, which
> > branch should I pull?
>
> Oops!!! The branch is lkmm-for-mingo.
>
> Please accept my apologies for the implicit maintainer treasure hunt!

No problem, was able to pull it!

I really like this formal description of of the Linux kernel memory coherency
model and the extensive documentation around it. Clearly a lot of effort went
into this work!

A couple of questions:

- Would it be possible to include all the nice descriptions of the litmus tests in
the tests themselves? Right now it's a bit weird that most of them come with
zero explanations, but the tools/memory-model/litmus-tests/README lists most of
them.

- Similary, some of the high level descriptions in tools/memory-model/README
should probably propagated into the source code files as well: for example
both tools/memory-model/lock.cat and linux-kernel.cat could be improved that
way.

- Could tools/memory-model/MAINTAINERS be added to the main Linux MAINTAINERS file
as well, like we do for other bits of tooling?

- There's no description about why the .bell file is called 'bell' and what
language/syntax it is in - I had to search around to figure out that it's a
"Bell extension" to .cat files. This aspect IMHO isn't really obvious to first
time readers so a bit more explanation would be nice.

- A high level question: have you considered calling it the "Linux kernel memory
coherency model", instead of the "Linux memory model"? Another naming would be
the "Linux kernel memory access model" as memory-barriers.txt calls it.
The "memory model" name is overly generic, ambiguous and somewhat misleading,
as we usually mean the virtual memory layout/model when we say "memory model".
GCC too uses it in that sense: 'small memory model' and 'large memory model' -
which too is about VM layout, not multiprocessing coherency.

- A long term question: have you considered and would it make sense to generate a
memory-barriers.txt like file directly into Documentation/locking/, using the
formal description? That way any changes/extensions/fixes to the model could be
tracked on a high level, without readers having to understand the formal
representation.

In any case, the base commit is certainly nice and clean and I've pulled it into
tip:locking/core for a v4.17 merge.

I believe these additional improvements (to the extent you agree with doing them!)
could/should be done as add-on commits on top of this existing commit.

Thanks,

Ingo