lkml.org 
[lkml]   [2017]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH tip/core/rcu 01/21] doc: READ_ONCE() now implies smp_barrier_depends()
On Mon, Dec 04, 2017 at 10:54:48PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 04, 2017 at 10:52:15AM -0800, Paul E. McKenney wrote:
> > On Mon, Dec 04, 2017 at 03:38:56PM +0000, David Howells wrote:
> > > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > > - Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
> > > > + Q = READ_ONCE(P); D = READ_ONCE(*Q);
> > > >
> > > > the CPU will issue the following memory operations:
> > > >
> > > > Q = LOAD P, D = LOAD *Q
> > >
> > > The CPU may now issue two barriers in addition to the loads, so should we show
> > > this? E.g.:
> > >
> > > Q = LOAD P, BARRIER, D = LOAD *Q, BARRIER
> >
> > Good point! How about as shown in the updated patch below?
>
> Humm, I thought the idea was to completely remove read_barrier_depends
> from the lkmm and memory-barriers.txt, making it an Alpha implementation
> detail.

That was indeed my hope, but a too-abrupt departure of DEC Alpha seemed
to be causing some confusion, so I jumped on David's suggested change. My
hope now is to slowly remove mention of DEC Alpha from the documentation.

Hmmm... Maybe we need an LWN article on how we are weaning the memory
model from its historical DEC Alpha influences? That might get the word
out more effectively.

Thanx, Paul

\
 
 \ /
  Last update: 2017-12-04 23:15    [W:3.771 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site