From: Andrea Arcangeli <aarcange@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
paulmck <paulmck@linux.vnet.ibm.com>,
Oleg Nesterov <oleg@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Hugh Dickins <hughd@google.com>
Subject: Re: thp and memory barrier assumptions
Date: Fri, 3 Aug 2012 21:30:20 +0200 [thread overview]
Message-ID: <20120803193020.GA1874@redhat.com> (raw)
In-Reply-To: <1343334805.32120.13.camel@twins>
On Thu, Jul 26, 2012 at 10:33:25PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-07-26 at 22:31 +0200, Peter Zijlstra wrote:
> > __do_huge_pmd_anonymous_page() contains:
> >
> > /*
> > * The spinlocking to take the lru_lock inside
> > * page_add_new_anon_rmap() acts as a full memory
> > * barrier to be sure clear_huge_page writes become
> > * visible after the set_pmd_at() write.
> > */
> > page_add_new_anon_rmap(page, vma, haddr);
> >
> >
> > page_add_new_anon_rmap() doesn't look to actually do a LOCK+UNLOCK
> > except for unevictable pages.
> >
> > But even if it did do an unconditional LOCK+UNLOCK that doesn't make a
> > full memory barrier, see Documentation/memory-barriers.txt.
> >
> > In particular:
> >
> > *A = a;
> > LOCK
> > UNLOCK
> > *B = b;
> >
> > may occur as:
> >
> > LOCK, STORE *B, STORE *A, UNLOCK
> >
>
I fixed that last year (I think Mel pointed out the bug) but I've been
so busy with other things I forgot to push that theoretical fix from
aa.git to -mm. As soon as autonuma is merged, I'll return to focus on
pushing the other pending patches in my queue that are being starved.
http://git.kernel.org/?p=linux/kernel/git/andrea/aa.git;a=commitdiff;h=d598a3f7ae4ca9d2c2a8653fbe790aab9b1a3141
Can you review it? If ok I'll submit it so it won't starve no
more. Also note the other bugfix that was in fair.c I think is only
needed with AutoNUMA applied this is why I didn't submit it
separately.
This can't affect x86 where even a locked bitop is the equivalent of a
full memory barrier.
> Also, what is that barrier() in handle_mm_fault() doing? And why doesn't
> it have a comment explaining that?
I added the docs below:
=====
>From ad51771a2c3fa697fa0267edda23b48d0b85f023 Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli <aarcange@redhat.com>
Date: Fri, 3 Aug 2012 21:10:44 +0200
Subject: [PATCH] thp: document barrier() in wrprotect THP fault path
Inline doc.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
mm/memory.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 420a449..9ec5bba 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3522,6 +3522,12 @@ retry:
pmd_t orig_pmd = *pmd;
int ret;
+ /*
+ * flush orig_pmd on the stack to avoid invalidating
+ * the pmd_trans_huge(orig_pmd) check and to allow
+ * do_huge_pmd_wp_page to run a reliable
+ * pmd_same(*pmd, orig_pmd).
+ */
barrier();
if (pmd_trans_huge(orig_pmd)) {
if (flags & FAULT_FLAG_WRITE &&
prev parent reply other threads:[~2012-08-03 19:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 20:31 thp and memory barrier assumptions Peter Zijlstra
2012-07-26 20:33 ` Peter Zijlstra
2012-08-03 19:30 ` Andrea Arcangeli [this message]
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=20120803193020.GA1874@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
/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.