All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: David Goldblatt <davidtgoldblatt@gmail.com>,
	<mathieu.desnoyers@efficios.com>,
	Florian Weimer <fweimer@redhat.com>, <triegel@redhat.com>,
	<libc-alpha@sourceware.org>, <andrea.parri@amarulasolutions.com>,
	<will.deacon@arm.com>, <peterz@infradead.org>,
	<boqun.feng@gmail.com>, <npiggin@gmail.com>,
	<dhowells@redhat.com>, <j.alglave@ucl.ac.uk>,
	<luc.maranget@inria.fr>, <akiyks@gmail.com>, <dlustig@nvidia.com>,
	<linux-arch@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Linux: Implement membarrier function
Date: Thu, 13 Dec 2018 21:26:47 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1812132110100.26937-100000@netrider.rowland.org> (raw)
In-Reply-To: <20181214002043.GP4170@linux.ibm.com>

On Thu, 13 Dec 2018, Paul E. McKenney wrote:

> > > A good next step would be to automatically generate random tests along
> > > with an automatically generated prediction, like I did for RCU a few
> > > years back.  I should be able to generalize my time-based cheat for RCU to
> > > also cover SRCU, though sys_membarrier() will require a bit more thought.
> > > (The time-based cheat was to have fixed duration RCU grace periods and
> > > RCU read-side critical sections, with the grace period duration being
> > > slightly longer than that of the critical sections.  The number of
> > > processes is of course limited by the chosen durations, but that limit
> > > can easily be made insanely large.)
> > 
> > Imagine that each sys_membarrier call takes a fixed duration and each 
> > other instruction takes slightly less (the idea being that each 
> > instruction is a critical section).  Instructions can be reordered 
> > (although not across a sys_membarrier call), but no matter how the 
> > reordering is done, the result is disallowed.

This turns out not to be right.  Instead, imagine that each 
sys_membarrier call takes a fixed duration, T.  Other instructions can 
take arbitrary amounts of time and can be reordered abitrarily, with 
two restrictions:

	Instructions cannot be reordered past a sys_membarrier call;

	If instructions A and B are reordered then the time duration
	from B to A must be less than T.

If you prefer, you can replace the second restriction with something a 
little more liberal:

	If A and B are reordered and A ends up executing after a 
	sys_membarrier call (on any CPU) then B cannot execute before 
	that sys_membarrier call.

Of course, this form is a consequence of the more restrictive form.

> It gets a bit trickier with interleavings of different combinations
> of RCU, SRCU, and sys_membarrier().  Yes, your cat code very elegantly
> sorts this out, but my goal is to be able to explain a given example
> to someone.

I don't think you're going to be able to fit different combinations of
RCU, SRCU, and sys_membarrier into this picture.  How would you allow
tests with incorrect interleaving, such as GP - memb - RSCS - nothing,
while forbidding similar tests with correct interleaving?

Alan


WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: David Goldblatt <davidtgoldblatt@gmail.com>,
	mathieu.desnoyers@efficios.com,
	Florian Weimer <fweimer@redhat.com>,
	triegel@redhat.com, libc-alpha@sourceware.org,
	andrea.parri@amarulasolutions.com, will.deacon@arm.com,
	peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com,
	dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr,
	akiyks@gmail.com, dlustig@nvidia.com, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Linux: Implement membarrier function
Date: Thu, 13 Dec 2018 21:26:47 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1812132110100.26937-100000@netrider.rowland.org> (raw)
In-Reply-To: <20181214002043.GP4170@linux.ibm.com>

On Thu, 13 Dec 2018, Paul E. McKenney wrote:

> > > A good next step would be to automatically generate random tests along
> > > with an automatically generated prediction, like I did for RCU a few
> > > years back.  I should be able to generalize my time-based cheat for RCU to
> > > also cover SRCU, though sys_membarrier() will require a bit more thought.
> > > (The time-based cheat was to have fixed duration RCU grace periods and
> > > RCU read-side critical sections, with the grace period duration being
> > > slightly longer than that of the critical sections.  The number of
> > > processes is of course limited by the chosen durations, but that limit
> > > can easily be made insanely large.)
> > 
> > Imagine that each sys_membarrier call takes a fixed duration and each 
> > other instruction takes slightly less (the idea being that each 
> > instruction is a critical section).  Instructions can be reordered 
> > (although not across a sys_membarrier call), but no matter how the 
> > reordering is done, the result is disallowed.

This turns out not to be right.  Instead, imagine that each 
sys_membarrier call takes a fixed duration, T.  Other instructions can 
take arbitrary amounts of time and can be reordered abitrarily, with 
two restrictions:

	Instructions cannot be reordered past a sys_membarrier call;

	If instructions A and B are reordered then the time duration
	from B to A must be less than T.

If you prefer, you can replace the second restriction with something a 
little more liberal:

	If A and B are reordered and A ends up executing after a 
	sys_membarrier call (on any CPU) then B cannot execute before 
	that sys_membarrier call.

Of course, this form is a consequence of the more restrictive form.

> It gets a bit trickier with interleavings of different combinations
> of RCU, SRCU, and sys_membarrier().  Yes, your cat code very elegantly
> sorts this out, but my goal is to be able to explain a given example
> to someone.

I don't think you're going to be able to fit different combinations of
RCU, SRCU, and sys_membarrier into this picture.  How would you allow
tests with incorrect interleaving, such as GP - memb - RSCS - nothing,
while forbidding similar tests with correct interleaving?

Alan

  reply	other threads:[~2018-12-14  2:26 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8736rldyzm.fsf@oldenburg.str.redhat.com>
     [not found] ` <1543444466.5493.220.camel@redhat.com>
     [not found]   ` <87y39c2dsg.fsf@oldenburg.str.redhat.com>
     [not found]     ` <1689938209.14804.1543502662882.JavaMail.zimbra@efficios.com>
     [not found]       ` <20181129150433.GH4170@linux.ibm.com>
     [not found]         ` <CAHD6eXcvx1bskbp-X+vuMYoMQiCLOt0PiCZ5FT1yFsda9Ud-yA@mail.gmail.com>
2018-12-06 21:54           ` [PATCH] Linux: Implement membarrier function Paul E. McKenney
2018-12-10 16:22             ` Alan Stern
2018-12-10 16:22               ` Alan Stern
2018-12-10 18:25               ` Paul E. McKenney
2018-12-11 16:21                 ` Alan Stern
2018-12-11 16:21                   ` Alan Stern
2018-12-11 19:08                   ` Paul E. McKenney
2018-12-11 20:09                     ` Alan Stern
2018-12-11 20:09                       ` Alan Stern
2018-12-11 21:22                       ` Paul E. McKenney
2018-12-12 17:07                         ` Paul E. McKenney
2018-12-12 18:04                           ` Alan Stern
2018-12-12 18:04                             ` Alan Stern
2018-12-12 19:42                             ` Paul E. McKenney
2018-12-12 21:32                               ` Alan Stern
2018-12-12 21:32                                 ` Alan Stern
2018-12-12 21:52                                 ` Paul E. McKenney
2018-12-12 22:12                                   ` Alan Stern
2018-12-12 22:12                                     ` Alan Stern
2018-12-12 22:49                                     ` Paul E. McKenney
2018-12-13 15:49                                       ` Alan Stern
2018-12-13 15:49                                         ` Alan Stern
2018-12-14  0:20                                         ` Paul E. McKenney
2018-12-14  2:26                                           ` Alan Stern [this message]
2018-12-14  2:26                                             ` Alan Stern
2018-12-14  5:20                                             ` Paul E. McKenney
2018-12-14 15:31                                           ` Alan Stern
2018-12-14 15:31                                             ` Alan Stern
2018-12-14 18:43                                             ` Paul E. McKenney
2018-12-14 21:39                                               ` Alan Stern
2018-12-14 21:39                                                 ` Alan Stern
2018-12-16 18:51                                                 ` Paul E. McKenney
2018-12-17 16:02                                                   ` Alan Stern
2018-12-17 16:02                                                     ` Alan Stern
2018-12-17 18:32                                                     ` Paul E. McKenney
2018-12-12 22:19                                   ` Paul E. McKenney
2018-12-11  6:42             ` David Goldblatt
2018-12-11 14:49               ` 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=Pine.LNX.4.44L0.1812132110100.26937-100000@netrider.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=akiyks@gmail.com \
    --cc=andrea.parri@amarulasolutions.com \
    --cc=boqun.feng@gmail.com \
    --cc=davidtgoldblatt@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=fweimer@redhat.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=npiggin@gmail.com \
    --cc=paulmck@linux.ibm.com \
    --cc=peterz@infradead.org \
    --cc=triegel@redhat.com \
    --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 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.