From: Andrew Morton <akpm@linux-foundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"Luck, Tony" <tony.luck@intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: ia64 broken by transparent huge pages - other arches too?
Date: Sun, 16 Jan 2011 13:10:39 -0800 [thread overview]
Message-ID: <20110116131039.0f0a9359.akpm@linux-foundation.org> (raw)
In-Reply-To: <AANLkTikZ+MmM9f0tidpccDAimtUkDvJ3N=3KE+xFxc63@mail.gmail.com>
On Sun, 16 Jan 2011 13:05:15 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, Jan 14, 2011 at 11:21 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > This is insane. Having such a massively invasive change to the whole mm,
> > barely tested on most architecture, and last I heard still generally
> > controversial being merged like that without even some integration
> > testing via -next makes no sense.
> >
> > Linus, wtf is going on ?
>
> I pretty much take anything from Andrew, unless I hate it (and the
> latest version of the transparent huge-page was ok).
>
> That said, I did think that Andrew's -mm tree was in -next, and there
> clearly is some serious problem wrt -mm and -next if this wasn't
> caught earlier there.
It's taking a while - Stephen and I are discussing a plan.
These problems were caused by a last-minute fixup which was more of a
breakup.
> I was also expecting the fixups to come through Andrew, and they
> haven't.
You've applied a couple directly, but this one is still outstanding.
> I can apply whatever people agree is sane, but right now I
> don't even know what the final patch for this problem is.
I believe it's the below. I haven't tested it yet and nor has anyone
else apart from Andrea, afaik.
From: Andrea Arcangeli <aarcange@redhat.com>
pmdp_get_and_clear/pmdp_clear_flush/pmdp_splitting_flush were trapped as
BUG() and they were defined only to diminish the risk of build issues on
not-x86 archs and to be consistent with the generic pte methods previously
defined in include/asm-generic/pgtable.h.
But they are causing more trouble than they were supposed to solve, so
it's simpler not to define them when THP is off.
This is also correcting the export of pmdp_splitting_flush which is
currently unused (x86 isn't using the generic implementation in
mm/pgtable-generic.c and no other arch needs that [yet]).
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Sam Ravnborg <sam@ravnborg.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/asm-generic/pgtable.h | 14 +++-----------
mm/pgtable-generic.c | 11 ++++-------
2 files changed, 7 insertions(+), 18 deletions(-)
diff -puN include/asm-generic/pgtable.h~mm-thp-remove-pmdp_get_and_clear-pmdp_clear_flush-pmdp_splitting_flush-methods-when-thp=n include/asm-generic/pgtable.h
--- a/include/asm-generic/pgtable.h~mm-thp-remove-pmdp_get_and_clear-pmdp_clear_flush-pmdp_splitting_flush-methods-when-thp=n
+++ a/include/asm-generic/pgtable.h
@@ -87,14 +87,6 @@ static inline pmd_t pmdp_get_and_clear(s
pmd_clear(mm, address, pmdp);
return pmd;
})
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-static inline pmd_t pmdp_get_and_clear(struct mm_struct *mm,
- unsigned long address,
- pmd_t *pmdp)
-{
- BUG();
- return __pmd(0);
-}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#endif
@@ -163,9 +155,9 @@ static inline void pmdp_set_wrprotect(st
#endif
#ifndef __HAVE_ARCH_PMDP_SPLITTING_FLUSH
-extern pmd_t pmdp_clear_flush(struct vm_area_struct *vma,
- unsigned long address,
- pmd_t *pmdp);
+extern pmd_t pmdp_splitting_flush(struct vm_area_struct *vma,
+ unsigned long address,
+ pmd_t *pmdp);
#endif
#ifndef __HAVE_ARCH_PTE_SAME
diff -puN mm/pgtable-generic.c~mm-thp-remove-pmdp_get_and_clear-pmdp_clear_flush-pmdp_splitting_flush-methods-when-thp=n mm/pgtable-generic.c
--- a/mm/pgtable-generic.c~mm-thp-remove-pmdp_get_and_clear-pmdp_clear_flush-pmdp_splitting_flush-methods-when-thp=n
+++ a/mm/pgtable-generic.c
@@ -92,32 +92,29 @@ pte_t ptep_clear_flush(struct vm_area_st
#endif
#ifndef __HAVE_ARCH_PMDP_CLEAR_FLUSH
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
pmd_t pmdp_clear_flush(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp)
{
pmd_t pmd;
-#ifndef CONFIG_TRANSPARENT_HUGEPAGE
- BUG();
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
VM_BUG_ON(address & ~HPAGE_PMD_MASK);
pmd = pmdp_get_and_clear(vma->vm_mm, address, pmdp);
flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
return pmd;
}
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#endif
#ifndef __HAVE_ARCH_PMDP_SPLITTING_FLUSH
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
pmd_t pmdp_splitting_flush(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp)
{
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
pmd_t pmd = pmd_mksplitting(*pmdp);
VM_BUG_ON(address & ~HPAGE_PMD_MASK);
set_pmd_at(vma->vm_mm, address, pmdp, pmd);
/* tlb flush only to serialize against gup-fast */
flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
- BUG();
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
}
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#endif
_
next prev parent reply other threads:[~2011-01-16 21:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 17:50 ia64 broken by transparent huge pages - other arches too? Luck, Tony
2011-01-14 17:50 ` Luck, Tony
2011-01-14 18:30 ` Andrea Arcangeli
2011-01-14 18:50 ` Tony Luck
2011-01-14 19:03 ` Andrea Arcangeli
2011-01-15 7:21 ` Benjamin Herrenschmidt
2011-01-15 15:59 ` Andrea Arcangeli
2011-01-15 16:47 ` James Bottomley
2011-01-15 17:23 ` Andrea Arcangeli
2011-01-15 19:02 ` Geert Uytterhoeven
2011-01-15 21:31 ` Benjamin Herrenschmidt
2011-01-16 21:05 ` Linus Torvalds
2011-01-16 21:10 ` Andrew Morton [this message]
2011-01-16 22:06 ` Andrea Arcangeli
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=20110116131039.0f0a9359.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=aarcange@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.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).