virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will.deacon@arm.com>,
	virtualization@lists.linux-foundation.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	user-mode-linux-devel@lists.sourceforge.net,
	linux-sh@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
	x86@kernel.org, xen-devel@lists.xenproject.org,
	Ingo Molnar <mingo@elte.hu>,
	linux-xtensa@linux-xtensa.org, james.hogan@imgtec.com,
	Arnd Bergmann <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	adi-buildroot-devel@lists.sourceforge.net, ddaney.cavm@gmail.com,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-metag@vger.kernel.orglinux-a
Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h
Date: Thu, 14 Jan 2016 13:29:13 -0800	[thread overview]
Message-ID: <20160114212913.GF3818@linux.vnet.ibm.com> (raw)
In-Reply-To: <56980C91.1010403@imgtec.com>

On Thu, Jan 14, 2016 at 01:01:05PM -0800, Leonid Yegoshin wrote:
> I need some time to understand your test examples. However,

Understood.

> On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
> >
> >
> >The WRC+addr+addr is OK because data dependencies are not required to be
> >transitive, in other words, they are not required to flow from one CPU to
> >another without the help of an explicit memory barrier.
> 
> I don't see any reliable way to fit WRC+addr+addr into "DATA
> DEPENDENCY BARRIERS" section recommendation to have data dependency
> barrier between read of a shared pointer/index and read the shared
> data based on that pointer. If you have this two reads, it doesn't
> matter the rest of scenario, you should put the dependency barrier
> in code anyway. If you don't do it in WRC+addr+addr scenario then
> after years it can be easily changed to different scenario which
> fits some of scenario in "DATA DEPENDENCY BARRIERS" section and
> fails.

The trick is that lockless_dereference() contains an
smp_read_barrier_depends():

#define lockless_dereference(p) \
({ \
	typeof(p) _________p1 = READ_ONCE(p); \
	smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
	(_________p1); \
})

Or am I missing your point?

> >   Transitivity is
> 
> Peter Zijlstra recently wrote: "In particular we're very much all
> 'confused' about the various notions of transitivity". I am confused
> too, so - please use some more simple way to explain your words.
> Sorry, but we need a common ground first.

OK, how about an example?  (Z6.3 in the ppcmem naming scheme.)

	int x, y, z;

	void cpu0(void)
	{
		WRITE_ONCE(x, 1);
		smp_wmb();
		WRITE_ONCE(y, 1);
	}

	void cpu1(void)
	{
		WRITE_ONCE(y, 2);
		smp_wmb();
		WRITE_ONCE(z, 1);
	}

	void cpu2(void)
	{
		r1 = READ_ONCE(z);
		smp_rmb();
		r2 = read_once(x);
	}

If smp_rmb() and smp_wmb() provided transitive ordering, then cpu2()
would see cpu0()'s ordering.  But they do not, so the ordering is
visible at best to the adjacent CPU.  This means that the final value
of y can be 2, while at the same time r1==1 && r2==0.

Now the full barrier, smp_mb(), does provide transitive ordering,
so if the three barriers in the above example are replaced with
smp_mb() the y==2 && r1==1 && r2==0 outcome will be prohibited.

So smp_mb() provides transitivity, as do pairs of smp_store_release()
and smp_read_acquire(), as do RCU grace periods.  The exact interactions
between transitive and non-transitive ordering is a work in progress.
That said, if a series of transitive segments ends in a write, which
connects to a single non-transitive segment starting with a read,
you should be good.  And in fact in the example above, you can replace
the smp_wmb()s with smp_mb() and leave the smp_rmb() and still
prohibit the "cyclic" outcome.

If you want a more formal definition, I must refer you back to the
ppcmem and herd references.

Does that help?

							Thanx, Paul

  reply	other threads:[~2016-01-14 21:29 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1452426622-4471-12-git-send-email-mst@redhat.com>
2016-01-12  1:14 ` [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin
     [not found] ` <56945366.2090504@imgtec.com>
2016-01-12  8:43   ` Michael S. Tsirkin
2016-01-12  9:27   ` Peter Zijlstra
2016-01-12 10:25     ` Peter Zijlstra
     [not found]     ` <20160112102555.GV6373@twins.programming.kicks-ass.net>
2016-01-12 10:40       ` Peter Zijlstra
2016-01-12 11:41         ` Will Deacon
2016-01-12 20:45           ` Leonid Yegoshin
     [not found]           ` <569565DA.2010903@imgtec.com>
2016-01-12 21:40             ` Peter Zijlstra
     [not found]             ` <20160112214003.GQ6357@twins.programming.kicks-ass.net>
2016-01-13  0:21               ` Leonid Yegoshin
2016-01-13 10:45             ` Will Deacon
     [not found]             ` <20160113104516.GE25458@arm.com>
2016-01-13 19:02               ` Leonid Yegoshin
     [not found]               ` <56969F4B.7070001@imgtec.com>
2016-01-13 20:48                 ` Peter Zijlstra
2016-01-13 20:58                   ` Leonid Yegoshin
2016-01-14 12:04                     ` Will Deacon
     [not found]                     ` <20160114120445.GB15828@arm.com>
2016-01-14 16:16                       ` Paul E. McKenney
2016-01-14 19:42                         ` Leonid Yegoshin
2016-01-14 20:15                           ` Peter Zijlstra
     [not found]                           ` <20160114201513.GI6357@twins.programming.kicks-ass.net>
2016-01-14 20:36                             ` Paul E. McKenney
2016-01-14 20:46                             ` Peter Zijlstra
2016-01-14 20:46                             ` Leonid Yegoshin
2016-01-14 21:34                               ` Paul E. McKenney
     [not found]                               ` <20160114213440.GG3818@linux.vnet.ibm.com>
2016-01-14 21:45                                 ` Leonid Yegoshin
2016-01-14 22:24                                   ` Paul E. McKenney
2016-01-14 23:04                                     ` Leonid Yegoshin
2016-01-14 20:12                       ` Leonid Yegoshin
     [not found]                       ` <56980145.5030901@imgtec.com>
2016-01-14 20:48                         ` Paul E. McKenney
2016-01-14 21:24                           ` Leonid Yegoshin
2016-01-14 22:20                             ` Paul E. McKenney
     [not found]                             ` <20160114222046.GH3818@linux.vnet.ibm.com>
2016-01-15  9:57                               ` Will Deacon
2016-01-15 18:54                                 ` Leonid Yegoshin
2016-01-26 10:24                               ` Peter Zijlstra
2016-01-26 10:32                                 ` Peter Zijlstra
2016-01-26 11:09                                   ` Will Deacon
     [not found]                                   ` <20160126110053.GA21553@arm.com>
2016-01-26 20:11                                     ` Paul E. McKenney
2016-01-27  8:35                                       ` [PATCH] documentation: Add disclaimer Peter Zijlstra
     [not found]                                       ` <20160127083546.GJ6357@twins.programming.kicks-ass.net>
2016-01-27 10:11                                         ` Will Deacon
2016-04-14 21:40                                         ` Paul E. McKenney
2016-01-27 14:57                                       ` David Howells
     [not found]                                       ` <15882.1453906627@warthog.procyon.org.uk>
2016-01-27 23:35                                         ` Paul E. McKenney
2016-01-28 20:02                                         ` David Howells
2016-04-14 21:40                                         ` Paul E. McKenney
2016-01-26 19:44                                 ` [v3,11/41] mips: reuse asm-generic/barrier.h Paul E. McKenney
2016-01-18  8:19                           ` Herbert Xu
     [not found]                           ` <20160118081929.GA30420@gondor.apana.org.au>
2016-01-18 15:46                             ` Paul E. McKenney
2016-01-26 16:52                               ` Boqun Feng
     [not found]                               ` <20160126165207.GB6029@fixme-laptop.cn.ibm.com>
2016-01-26 17:22                                 ` Peter Zijlstra
2016-01-26 19:44                                   ` Linus Torvalds
     [not found]                                   ` <CA+55aFzcC6C8imPs5vk4yH1Y2YHjnAdFM9HCkVs04COxuDQH6w@mail.gmail.com>
2016-01-26 20:10                                     ` Paul E. McKenney
     [not found]                                     ` <20160126201037.GU4503@linux.vnet.ibm.com>
2016-01-26 22:15                                       ` Linus Torvalds
     [not found]                                       ` <CA+55aFxjb+2rs2wVHtiSCcOzgMrE8H=yDeNcjyujPQudDCtLgw@mail.gmail.com>
2016-01-26 22:33                                         ` Linus Torvalds
     [not found]                                         ` <CA+55aFwxTJd+uibcxtZD3tGnj_n=LMwyAa0s8qyx_OF0OMWQkA@mail.gmail.com>
2016-01-26 23:29                                           ` Paul E. McKenney
2016-01-26 23:45                                             ` Linus Torvalds
     [not found]                                             ` <CA+55aFyD94yaA1QzXgfeO18T-czY3TVUi5n6r-9jOUObDeR-zQ@mail.gmail.com>
2016-01-27  0:57                                               ` Paul E. McKenney
2016-01-27  2:04                                             ` Boqun Feng
     [not found]                                             ` <20160127020447.GA1293@fixme-laptop.cn.ibm.com>
2016-01-27 23:30                                               ` Paul E. McKenney
2016-01-27  7:51                                           ` Peter Zijlstra
2016-01-27  8:05                                             ` Linus Torvalds
2016-01-26 19:51                                 ` Paul E. McKenney
2016-01-13 22:26               ` Leonid Yegoshin
     [not found]               ` <5696CF08.8080700@imgtec.com>
2016-01-14  9:24                 ` Michael S. Tsirkin
2016-01-14 12:14                 ` Will Deacon
     [not found]                 ` <20160114121449.GC15828@arm.com>
2016-01-14 19:28                   ` Leonid Yegoshin
     [not found]                   ` <5697F6D2.60409@imgtec.com>
2016-01-14 20:34                     ` Paul E. McKenney
2016-01-14 21:01                       ` Leonid Yegoshin
2016-01-14 21:29                         ` Paul E. McKenney [this message]
2016-01-14 21:36                           ` Leonid Yegoshin
2016-01-14 22:55                             ` Paul E. McKenney
2016-01-14 23:33                               ` Leonid Yegoshin
2016-01-15  0:47                                 ` Paul E. McKenney
2016-01-15  1:07                                   ` Leonid Yegoshin
2016-01-27 11:26                                     ` Maciej W. Rozycki
     [not found]                                     ` <alpine.DEB.2.00.1601271116520.5958@tp.orcam.me.uk>
2016-01-28  0:48                                       ` Leonid Yegoshin
2016-01-29 13:38                                         ` Maciej W. Rozycki
2016-01-28  0:58                                       ` Leonid Yegoshin
2016-01-27 10:40                                   ` Ralf Baechle
     [not found]                                   ` <20160127104032.GB2939@linux-mips.org>
2016-01-27 12:09                                     ` Maciej W. Rozycki
2016-01-15 10:24                               ` Will Deacon
2016-01-15 17:54                                 ` Paul E. McKenney
2016-01-15 19:28                                   ` Paul E. McKenney
2016-01-25 14:41                                     ` Will Deacon
     [not found]                                     ` <20160125144133.GB22927@arm.com>
2016-01-26  1:06                                       ` Paul E. McKenney
     [not found]                                       ` <20160126010646.GH4503@linux.vnet.ibm.com>
2016-01-26 12:10                                         ` Will Deacon
     [not found]                                         ` <20160126121010.GD21553@arm.com>
2016-01-26 23:37                                           ` Paul E. McKenney
2016-01-27 10:23                                             ` Will Deacon
2016-01-15  8:55                           ` Peter Zijlstra
     [not found]                           ` <20160115085554.GF3421@worktop>
2016-01-15  9:13                             ` Peter Zijlstra
2016-01-15 17:46                               ` Paul E. McKenney
2016-01-15 21:27                                 ` Peter Zijlstra
2016-01-15 21:58                                   ` Paul E. McKenney
     [not found]                                   ` <20160115215853.GC3818@linux.vnet.ibm.com>
2016-01-25 16:42                                     ` Will Deacon
2016-01-26  6:03                                       ` Paul E. McKenney
2016-01-26 10:19                                         ` Peter Zijlstra
2016-01-26 12:16                                         ` Will Deacon
2016-01-26 14:35                                           ` Boqun Feng
2016-01-26 19:58                                           ` Paul E. McKenney
     [not found]                                           ` <20160126195820.GS4503@linux.vnet.ibm.com>
2016-01-27 10:25                                             ` Will Deacon
2016-01-27 23:32                                               ` Paul E. McKenney
     [not found]                                         ` <20160126101927.GD6357@twins.programming.kicks-ass.net>
2016-01-26 20:13                                           ` Paul E. McKenney
2016-01-27  8:39                                             ` Peter Zijlstra
2016-01-15 17:39                             ` Paul E. McKenney
2016-01-15 21:29                               ` Peter Zijlstra
2016-01-15 22:01                                 ` Paul E. McKenney
2016-01-25 18:02                               ` Will Deacon
     [not found]                               ` <20160125180234.GA26732@arm.com>
2016-01-26  6:12                                 ` Paul E. McKenney
2016-01-26 10:15                                   ` Peter Zijlstra
     [not found]   ` <20160112103913-mutt-send-email-mst@redhat.com>
2016-01-12  9:51     ` Peter Zijlstra

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=20160114212913.GF3818@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=Leonid.Yegoshin@imgtec.com \
    --cc=adi-buildroot-devel@lists.sourceforge.net \
    --cc=arnd@arndb.de \
    --cc=ddaney.cavm@gmail.com \
    --cc=hpa@zytor.com \
    --cc=james.hogan@imgtec.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-metag@vger.kernel.orglinux-a \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mingo@elte.hu \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=mst@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tglx@linutronix.de \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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;
as well as URLs for NNTP newsgroup(s).