All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christoph Lameter <cl@gentwo.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Tejun Heo <tj@kernel.org>,
	David Howells <dhowells@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] percpu: add data dependency barrier in percpu accessors and operations
Date: Tue, 15 Jul 2014 08:41:49 -0700	[thread overview]
Message-ID: <CA+55aFzP_GZaTYcUg7CN+Sz5ZeWX2CgxX3hig2gyBxhCCayamA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1407150952580.10593@gentwo.org>

Christoph, stop arguing. Trust me, Paul knows memory ordering. You
clearly do *not*.

On Tue, Jul 15, 2014 at 8:06 AM, Christoph Lameter <cl@gentwo.org> wrote:
>
> The cachelines will be evicted from the other processors at
> initialization. alloc_percpu *itself* zeroes all data on each percpu areas
> before returning the offset to the percpu data structure. See
> pcpu_populate_chunk(). At that point *all* other processors have those
> cachelines no longer in their caches. The initialization done with values
> specific to the subsystem is not that important.

In practice, with enough instructions in the CPU queues and
sufficiently small write buffers etc (or with a sufficiently ordered
CPU core, like x86), that may often be true. But there is absolutely
zero reason to think it's always true.

On the writer side, if there isn't a write barrier, the actual writes
can be visible to other CPU's in arbitrary order. *Including* the
visibility of the offset before the zeroing. Really.

On the reader side, for all sane CPU's, reading the offset and then
reading data from that offset is an implicit barrier. But "all sane"
is not "all". On alpha, reading the offset does NOT guarantee that you
see later data when you use that offset to read data. In theory, it
could be due to value prediction, but in practice it's actually due to
segmented caches, so that one part of the cache has seen data that
arrived "later" (ie written _after_ the wmb on the writing CPU)
_before_ it sees data that arrived earlier. That's what the
"smp_read_barrier_depends()" protects against.

> The return value of the function is only available after
> pcpu_populate_chunk() returns.

Really, "before" and "after" have ABSOLUTELY NO MEANING unless you
have a barrier. And you're arguing against those barriers. So you
cannot use "before" as an argument, since in your world, no such thing
even exists!

There are other arguments, but they basically boil down to "no other
CPU ever accesses the per-cpu data of *this* CPU" (wrong) or "the
users will do their own barriers" (maybe true, maybe not). Your "value
is only available after" argument really isn't an argument. Not
without those barriers.

            Linus

  reply	other threads:[~2014-07-15 15:41 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12 13:56 [PATCH RFC] percpu: add data dependency barrier in percpu accessors and operations Tejun Heo
2014-06-12 15:34 ` Paul E. McKenney
2014-06-12 15:52   ` Tejun Heo
2014-06-17 14:41     ` Paul E. McKenney
2014-06-17 15:27       ` Tejun Heo
2014-06-17 15:56         ` Christoph Lameter
2014-06-17 16:00           ` Tejun Heo
2014-06-17 16:05             ` Tejun Heo
2014-06-17 16:28               ` Christoph Lameter
     [not found]                 ` <CA+55aFxHr8JXwDR-4g4z1mkXvZRtY=OosYcUMPZRD2upfooS1w@mail.gmail.com>
2014-06-17 18:47                   ` Christoph Lameter
2014-06-17 18:55                     ` Paul E. McKenney
2014-06-17 19:39                       ` Christoph Lameter
2014-06-17 19:47                         ` Tejun Heo
2014-06-17 19:56                         ` Paul E. McKenney
2014-06-19 20:39                           ` Christoph Lameter
2014-06-17 16:57         ` Paul E. McKenney
2014-06-17 18:56           ` Tejun Heo
2014-06-17 19:42             ` Christoph Lameter
2014-06-17 20:44               ` Tejun Heo
2014-07-09  0:55         ` Rusty Russell
2014-07-14 11:39           ` Paul E. McKenney
2014-07-14 15:22             ` Christoph Lameter
2014-07-15 10:11               ` Paul E. McKenney
2014-07-15 14:06                 ` Christoph Lameter
2014-07-15 14:32                   ` Paul E. McKenney
2014-07-15 15:06                     ` Christoph Lameter
2014-07-15 15:41                       ` Linus Torvalds [this message]
2014-07-15 16:12                         ` Christoph Lameter
     [not found]                           ` <CA+55aFxU166V5-vH4vmK9OBdTZKyede=71RjjbOVSN9Qh+Se+A@mail.gmail.com>
2014-07-15 17:45                             ` Paul E. McKenney
2014-07-15 17:41                       ` Paul E. McKenney
2014-07-16 14:40                         ` Christoph Lameter
2014-07-15 11:50             ` Rusty Russell
2014-06-17 19:27 ` Christoph Lameter
2014-06-17 19:40   ` Paul E. McKenney
2014-06-19 20:42     ` Christoph Lameter
2014-06-19 20:46       ` Tejun Heo
2014-06-19 21:11         ` Christoph Lameter
2014-06-19 21:15           ` Tejun Heo
2014-06-20 15:23             ` Christoph Lameter
2014-06-20 15:52               ` Tejun Heo
2014-06-19 20:51       ` Paul E. McKenney
2014-06-20 15:29         ` Christoph Lameter
2014-06-20 15:50           ` 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=CA+55aFzP_GZaTYcUg7CN+Sz5ZeWX2CgxX3hig2gyBxhCCayamA@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rusty@rustcorp.com.au \
    --cc=tj@kernel.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 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.