From: Nick Piggin <npiggin@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Hugh Dickins <hugh@veritas.com>,
linux-arch@vger.kernel.org,
Linux Memory Management List <linux-mm@kvack.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [rfc] data race in page table setup/walking?
Date: Thu, 1 May 2008 02:29:55 +0200 [thread overview]
Message-ID: <20080501002955.GA11312@wotan.suse.de> (raw)
In-Reply-To: <alpine.LFD.1.10.0804300848390.2997@woody.linux-foundation.org>
On Wed, Apr 30, 2008 at 08:53:44AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 30 Apr 2008, Nick Piggin wrote:
> >
> > Actually, aside, all those smp_wmb() things in pgtable-3level.h can
> > probably go away if we cared: because we could be sneaky and leverage
> > the assumption that top and bottom will always be in the same cacheline
> > and thus should be shielded from memory consistency problems :)
>
> Umm.
>
> Why would we care, since smp_wmb() is a no-op? (Yea, it's a compiler
> barrier, big deal, it's not going to cost us anything).
Oh there needs to be a compiler barrier there. I was just saying...
I don't actually think we care (whether or not I'm right).
> Also, write barriers are not about cacheline access order, they tend to be
> more about the write *buffer*, ie before the write even hits the cache
> line. And a write coudl easily pass another write in the write buffer if
> there is (for example) a dependency on the address.
>
> So even if they are in the same cacheline, if the first write needs an
> offset addition, and the second one does not, it could easily be that the
> second one hits the write buffer first (together with some alias
> detection that re-does the things if they alias).
>
> Of course, on x86, the write ordering is strictly defined, and even if the
> CPU reorders writes they are guaranteed to never show up re-ordered, so
> this is not an issue. But I wanted to point out that memory ordering is
> *not* just about cachelines, and being in the same cacheline is no
> guarantee of anything, even if it can have *some* effects.
Well it is a guarantee about cache coherency presumably, but I guess
you're taking that for granted.
But I'm surprised that two writes to the same cacheline (different
words) can be reordered. Of course write buffers are technically outside
the coherency domain, but I would have thought any implementation will
actually treat writes to the same line as aliasing. Is there a counter
example?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-05-01 0:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 5:00 Nick Piggin
2008-04-29 5:08 ` Benjamin Herrenschmidt
2008-04-29 5:41 ` Nick Piggin
2008-04-29 10:56 ` David Miller, Nick Piggin
2008-04-29 12:36 ` Hugh Dickins
2008-04-29 21:37 ` Benjamin Herrenschmidt
2008-04-29 22:47 ` Hugh Dickins
2008-04-30 0:09 ` Benjamin Herrenschmidt
2008-04-30 6:03 ` Nick Piggin
2008-04-30 6:05 ` David Miller, Nick Piggin
2008-04-30 6:17 ` Nick Piggin
2008-04-30 11:14 ` Hugh Dickins
2008-05-01 0:35 ` Nick Piggin
2008-05-01 12:45 ` Hugh Dickins
2008-04-30 15:53 ` Linus Torvalds
2008-05-01 0:29 ` Nick Piggin [this message]
2008-05-01 3:24 ` Linus Torvalds
2008-05-02 1:20 ` Nick Piggin
2008-05-02 1:33 ` Linus Torvalds
2008-05-02 1:43 ` Nick Piggin
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=20080501002955.GA11312@wotan.suse.de \
--to=npiggin@suse.de \
--cc=benh@kernel.crashing.org \
--cc=hugh@veritas.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.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