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: Fri, 2 May 2008 03:20:07 +0200 [thread overview]
Message-ID: <20080502012006.GD30768@wotan.suse.de> (raw)
In-Reply-To: <alpine.LFD.1.10.0804302020050.5994@woody.linux-foundation.org>
On Wed, Apr 30, 2008 at 08:24:48PM -0700, Linus Torvalds wrote:
>
> On Thu, 1 May 2008, Nick Piggin wrote:
> > 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?
>
> I don't know if anybody does it, but no, normally I would *not* expect any
> alias logic to have anything to do with cachelines. Aliasing within a
> cacheline is so common (spills to the stack, if nothing else) that if the
> CPU has some write buffer alias logic, I'd expect it to be byte or perhaps
> word-granular.
>
> So I think that at least in theory it is quite possible that a later write
> hits the same cacheline first, just because the write data or address got
> resolved first and the architecture allows out-of-order memory accesses.
I guess it is possible. But at least in the case of write address, you'd
have to wait for later stores anyway in order to do the alias detection,
which might be the most common case.
For other dependencies yes, although I would have thought that you'd be
better off to wait for the earlier write and so they can be combined into
a single cache transaction. The easy part of stores is queueing them,
the hard part is moving them out to cache.
Anyway I'm speculating at this point. You do raise a valid issue, so
obviously we can't make any such assumptions without verifying it on a
per-arch basis ;) I'm just interested to know whether this happens on
any CPU we run on.
--
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-02 1:20 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
2008-05-01 3:24 ` Linus Torvalds
2008-05-02 1:20 ` Nick Piggin [this message]
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=20080502012006.GD30768@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