From: "Dr. David Alan Gilbert" <dave@treblig.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
Hugh Dickins <hughd@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <npiggin@kernel.dk>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC] page-table walkers vs memory order
Date: Sun, 5 Aug 2012 01:10:51 +0100 [thread overview]
Message-ID: <20120805001051.GC1255@gallifrey> (raw)
In-Reply-To: <20120804231151.GK3307@linux.vnet.ibm.com>
* Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> On Sat, Aug 04, 2012 at 11:59:10PM +0100, Dr. David Alan Gilbert wrote:
<snip>
> > A compiler could decide to dereference it using a non-faulting load,
> > do the calculations or whatever on the returned value of the non-faulting
> > load, and then check whether the load actually faulted, and whether the
> > address matched the prediction before it did a store based on it's
> > guess.
>
> Or the compiler could record a recovery address in a per-thread variable
> before doing the speculative reference. The page-fault handler could
> consult the per-thread variable and take appropriate action.
The difference is that I'd expect a compiler writer to think that
they've got a free hand in terms of instruction usage that the OS/library
doesn't see - if it's in the instruction manual and it's marked as user
space and non-faulting I'd say it's fair game; once they know that they're
going to take a fault or mark pages specially then they already know they're
going to have to cooperate with the OS, or worry about what other
normal library calls are going to do.
(A bit of googling seems to suggest IA64 and SPARC have played around
with non-faulting load optimisations, but I can't tell how much.)
> But both this approach and your approach are vulnerable to things like
> having the speculation area mapped to (say) MMIO space. Not good!
Not good for someone doing MMIO, but from an evil-compiler point
of view, they might well assume that a pointer is to memory
unless someone has made an effort to tell them otherwise (not that
there is a good standard to do that).
> So I am with Andrea on this one -- there would need to be some handshake
> between kernel and compiler to avoid messing with possibly-unsafe
> mappings. And I am still not much in favor of value speculation. ;-)
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ gro.gilbert @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
--
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:[~2012-08-05 0:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-23 17:34 [RFC] page-table walkers vs memory order Peter Zijlstra
2012-07-23 19:27 ` Paul E. McKenney
2012-07-24 21:51 ` Hugh Dickins
2012-07-25 17:56 ` Paul E. McKenney
2012-07-25 20:26 ` Hugh Dickins
2012-07-25 21:12 ` Paul E. McKenney
2012-07-25 22:09 ` Hugh Dickins
2012-07-25 22:37 ` Paul E. McKenney
2012-07-26 8:11 ` Peter Zijlstra
2012-07-30 19:21 ` Jamie Lokier
2012-07-30 20:28 ` Paul E. McKenney
2012-07-26 20:39 ` Peter Zijlstra
2012-07-27 19:22 ` Hugh Dickins
2012-07-27 19:39 ` Paul E. McKenney
2012-08-04 14:37 ` Andrea Arcangeli
2012-08-04 22:02 ` Paul E. McKenney
2012-08-04 22:47 ` Andrea Arcangeli
2012-08-04 22:59 ` Dr. David Alan Gilbert
2012-08-04 23:11 ` Paul E. McKenney
2012-08-05 0:10 ` Dr. David Alan Gilbert [this message]
2012-08-04 23:06 ` 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=20120805001051.GC1255@gallifrey \
--to=dave@treblig.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@kernel.dk \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).