linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Hugh Dickins <hughd@google.com>
Cc: mpe@ellerman.id.au, Andrew Morton <akpm@linux-foundation.org>,
	benh@kernel.crashing.org, Tony Luck <tony.luck@intel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	trinity@vger.kernel.org
Subject: Re: [PATCH] hugetlb: restrict hugepage_migration_support() to x86_64 (Re: BUG at mm/memory.c:1489!)
Date: Thu, 29 May 2014 22:56:00 -0400	[thread overview]
Message-ID: <5387f356.c2ebc20a.19f7.63f7SMTPIN_ADDED_BROKEN@mx.google.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1405291408430.10286@eggly.anvils>

On Thu, May 29, 2014 at 03:04:57PM -0700, Hugh Dickins wrote:
> On Thu, 29 May 2014, Naoya Horiguchi wrote:
> > 
> > Curretly hugepage migration is available for all archs which support pmd-level
> > hugepage, but testing is done only for x86_64 and there're bugs for other archs.
> 
> And even for x86_64 I think: the follow_huge_pmd() locking issue I
> mentioned.  But I agree that's a different kind of bug, and probably
> not cause to disable the feature even on x86_64 at this stage - but
> cause to fix it in a different patch Cc stable when you have a moment.

Yes, I promise to do it.

> > So to avoid breaking such archs, this patch limits the availability strictly to
> > x86_64 until developers of other archs get interested in enabling this feature.
> 
> Hmm, I don't like the sound of "until developers of other archs get
> interested in enabling this feature".  Your choice, I suppose, but I
> had been expecting you to give them a little more help than that, by
> fixing up the follow_huge_addr() and locking as you expect it to be
> (and whatever Michael's subsequent remove_migration_pte() crash comes
> from - maybe obvious with a little thought, but I haven't), then
> pinging those architectures to give it a try and enable if they wish.

I agree, I'll do this (maybe starting by adding more comment to help enable
on other archs) after fixing locking problem.

> Perhaps I'm expecting too much, and you haven't the time; doubt I have.

I can not say when, but I want to do it in a few months.

> I believe your patch below is incomplete, or perhaps you were
> expecting to layer it on top of my follow_huge_addr get_page one.
> No, I think we should throw mine away if you're going to disable
> the feature on most architectures for now (and once the locking is
> corrected, my get_page after follow_huge_addr will be wrong anyway).

OK, you dropped the patch, so follow_page(FOLL_GET) should not called for
hugepages on non-x86_64 archs.

> What I think you're missing is an adjustment to your 71ea2efb1e93
> ("mm: migrate: remove VM_HUGETLB from vma flag check in vma_migratable()"):
> doesn't vma_migratable() need to test VM_HUGETLB when
> !CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION? 

Right, that looks to me a good precheck to skip hugepage.

> Then we are saved from
> reaching the follow_huge_addr() BUG; and avoid the weird preparation
> for migrating HUGETLB pages on architectures which do not support it.
> 
> But yes, I think your disablement approach is the right thing for 3.15.
> 
> > 
> > Reported-by: Michael Ellerman <mpe@ellerman.id.au>
> > Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> > Cc: stable@vger.kernel.org # 3.12+
> > ---
> >  arch/arm/mm/hugetlbpage.c     |  5 -----
> >  arch/arm64/mm/hugetlbpage.c   |  5 -----
> >  arch/ia64/mm/hugetlbpage.c    |  5 -----
> >  arch/metag/mm/hugetlbpage.c   |  5 -----
> >  arch/mips/mm/hugetlbpage.c    |  5 -----
> >  arch/powerpc/mm/hugetlbpage.c | 10 ----------
> >  arch/s390/mm/hugetlbpage.c    |  5 -----
> >  arch/sh/mm/hugetlbpage.c      |  5 -----
> >  arch/sparc/mm/hugetlbpage.c   |  5 -----
> >  arch/tile/mm/hugetlbpage.c    |  5 -----
> >  arch/x86/Kconfig              |  4 ++++
> >  arch/x86/mm/hugetlbpage.c     | 10 ----------
> >  include/linux/hugetlb.h       | 10 ++++++----
> >  mm/Kconfig                    |  3 +++
> >  14 files changed, 13 insertions(+), 69 deletions(-)
> > 
> > diff --git a/arch/arm/mm/hugetlbpage.c b/arch/arm/mm/hugetlbpage.c
> > index 54ee6163c181..66781bf34077 100644
> > --- a/arch/arm/mm/hugetlbpage.c
> > +++ b/arch/arm/mm/hugetlbpage.c
> > @@ -56,8 +56,3 @@ int pmd_huge(pmd_t pmd)
> >  {
> >  	return pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT);
> >  }
> > -
> > -int pmd_huge_support(void)
> > -{
> > -	return 1;
> > -}
> > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > index 5e9aec358306..2fc8258bab2d 100644
> > --- a/arch/arm64/mm/hugetlbpage.c
> > +++ b/arch/arm64/mm/hugetlbpage.c
> > @@ -54,11 +54,6 @@ int pud_huge(pud_t pud)
> >  	return !(pud_val(pud) & PUD_TABLE_BIT);
> >  }
> >  
> > -int pmd_huge_support(void)
> > -{
> > -	return 1;
> > -}
> > -
> >  static __init int setup_hugepagesz(char *opt)
> >  {
> >  	unsigned long ps = memparse(opt, &opt);
> > diff --git a/arch/ia64/mm/hugetlbpage.c b/arch/ia64/mm/hugetlbpage.c
> > index 68232db98baa..76069c18ee42 100644
> > --- a/arch/ia64/mm/hugetlbpage.c
> > +++ b/arch/ia64/mm/hugetlbpage.c
> > @@ -114,11 +114,6 @@ int pud_huge(pud_t pud)
> >  	return 0;
> >  }
> >  
> > -int pmd_huge_support(void)
> > -{
> > -	return 0;
> > -}
> > -
> >  struct page *
> >  follow_huge_pmd(struct mm_struct *mm, unsigned long address, pmd_t *pmd, int write)
> >  {
> > diff --git a/arch/metag/mm/hugetlbpage.c b/arch/metag/mm/hugetlbpage.c
> > index 042431509b56..3c52fa6d0f8e 100644
> > --- a/arch/metag/mm/hugetlbpage.c
> > +++ b/arch/metag/mm/hugetlbpage.c
> > @@ -110,11 +110,6 @@ int pud_huge(pud_t pud)
> >  	return 0;
> >  }
> >  
> > -int pmd_huge_support(void)
> > -{
> > -	return 1;
> > -}
> > -
> >  struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
> >  			     pmd_t *pmd, int write)
> >  {
> > diff --git a/arch/mips/mm/hugetlbpage.c b/arch/mips/mm/hugetlbpage.c
> > index 77e0ae036e7c..4ec8ee10d371 100644
> > --- a/arch/mips/mm/hugetlbpage.c
> > +++ b/arch/mips/mm/hugetlbpage.c
> > @@ -84,11 +84,6 @@ int pud_huge(pud_t pud)
> >  	return (pud_val(pud) & _PAGE_HUGE) != 0;
> >  }
> >  
> > -int pmd_huge_support(void)
> > -{
> > -	return 1;
> > -}
> > -
> >  struct page *
> >  follow_huge_pmd(struct mm_struct *mm, unsigned long address,
> >  		pmd_t *pmd, int write)
> > diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> > index eb923654ba80..7e70ae968e5f 100644
> > --- a/arch/powerpc/mm/hugetlbpage.c
> > +++ b/arch/powerpc/mm/hugetlbpage.c
> > @@ -86,11 +86,6 @@ int pgd_huge(pgd_t pgd)
> >  	 */
> >  	return ((pgd_val(pgd) & 0x3) != 0x0);
> >  }
> > -
> > -int pmd_huge_support(void)
> > -{
> > -	return 1;
> > -}
> >  #else
> >  int pmd_huge(pmd_t pmd)
> >  {
> > @@ -106,11 +101,6 @@ int pgd_huge(pgd_t pgd)
> >  {
> >  	return 0;
> >  }
> > -
> > -int pmd_huge_support(void)
> > -{
> > -	return 0;
> > -}
> >  #endif
> >  
> >  pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
> > diff --git a/arch/s390/mm/hugetlbpage.c b/arch/s390/mm/hugetlbpage.c
> > index 0727a55d87d9..0ff66a7e29bb 100644
> > --- a/arch/s390/mm/hugetlbpage.c
> > +++ b/arch/s390/mm/hugetlbpage.c
> > @@ -220,11 +220,6 @@ int pud_huge(pud_t pud)
> >  	return 0;
> >  }
> >  
> > -int pmd_huge_support(void)
> > -{
> > -	return 1;
> > -}
> > -
> >  struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
> >  			     pmd_t *pmdp, int write)
> >  {
> > diff --git a/arch/sh/mm/hugetlbpage.c b/arch/sh/mm/hugetlbpage.c
> > index 0d676a41081e..d7762349ea48 100644
> > --- a/arch/sh/mm/hugetlbpage.c
> > +++ b/arch/sh/mm/hugetlbpage.c
> > @@ -83,11 +83,6 @@ int pud_huge(pud_t pud)
> >  	return 0;
> >  }
> >  
> > -int pmd_huge_support(void)
> > -{
> > -	return 0;
> > -}
> > -
> >  struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
> >  			     pmd_t *pmd, int write)
> >  {
> > diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
> > index 9bd9ce80bf77..d329537739c6 100644
> > --- a/arch/sparc/mm/hugetlbpage.c
> > +++ b/arch/sparc/mm/hugetlbpage.c
> > @@ -231,11 +231,6 @@ int pud_huge(pud_t pud)
> >  	return 0;
> >  }
> >  
> > -int pmd_huge_support(void)
> > -{
> > -	return 0;
> > -}
> > -
> >  struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
> >  			     pmd_t *pmd, int write)
> >  {
> > diff --git a/arch/tile/mm/hugetlbpage.c b/arch/tile/mm/hugetlbpage.c
> > index 0cb3bbaa580c..e514899e1100 100644
> > --- a/arch/tile/mm/hugetlbpage.c
> > +++ b/arch/tile/mm/hugetlbpage.c
> > @@ -166,11 +166,6 @@ int pud_huge(pud_t pud)
> >  	return !!(pud_val(pud) & _PAGE_HUGE_PAGE);
> >  }
> >  
> > -int pmd_huge_support(void)
> > -{
> > -	return 1;
> > -}
> > -
> >  struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
> >  			     pmd_t *pmd, int write)
> >  {
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 25d2c6f7325e..0cf6a7d0a93e 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1871,6 +1871,10 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK
> >  	def_bool y
> >  	depends on X86_64 || X86_PAE
> >  
> > +config ARCH_ENABLE_HUGEPAGE_MIGRATION
> > +	def_bool y
> > +	depends on X86_64 || MIGRATION
> > +
> 
> Should that be X86_64 && MIGRATION?  X86_64 && HUGETLB_PAGE && MIGRATION?
> Maybe it doesn't matter.

Ouch, "&&" is what I meant, and HUGETLB_PAGE is also fine.

> Yes, I agree a per-arch config option is better than all those
> pmd_huge_support() functions, especially all the ones saying 0.
>
> >  menu "Power management and ACPI options"
> >  
> >  config ARCH_HIBERNATION_HEADER
> > diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
> > index 8c9f647ff9e1..8b977ebf9388 100644
> > --- a/arch/x86/mm/hugetlbpage.c
> > +++ b/arch/x86/mm/hugetlbpage.c
> > @@ -58,11 +58,6 @@ follow_huge_pmd(struct mm_struct *mm, unsigned long address,
> >  {
> >  	return NULL;
> >  }
> > -
> > -int pmd_huge_support(void)
> > -{
> > -	return 0;
> > -}
> >  #else
> >  
> >  struct page *
> > @@ -80,11 +75,6 @@ int pud_huge(pud_t pud)
> >  {
> >  	return !!(pud_val(pud) & _PAGE_PSE);
> >  }
> > -
> > -int pmd_huge_support(void)
> > -{
> > -	return 1;
> > -}
> >  #endif
> >  
> >  #ifdef CONFIG_HUGETLB_PAGE
> > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > index 63214868c5b2..61c2e349af64 100644
> > --- a/include/linux/hugetlb.h
> > +++ b/include/linux/hugetlb.h
> > @@ -385,15 +385,18 @@ static inline pgoff_t basepage_index(struct page *page)
> >  
> >  extern void dissolve_free_huge_pages(unsigned long start_pfn,
> >  				     unsigned long end_pfn);
> > -int pmd_huge_support(void);
> >  /*
> > - * Currently hugepage migration is enabled only for pmd-based hugepage.
> > + * Currently hugepage migration is enabled only for x86_64.
> 
> You don't want to have to update that comment every time an architecture
> opts in.  No need for any comment here, I think, the name is good enough
> (though hugepage_migration_supported() would be better).

Ah, OK. I'll remove this comment.

Thanks,
Naoya Horiguchi

> >   * This function will be updated when hugepage migration is more widely
> >   * supported.
> >   */
> >  static inline int hugepage_migration_support(struct hstate *h)
> >  {
> > -	return pmd_huge_support() && (huge_page_shift(h) == PMD_SHIFT);
> > +#ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
> > +	return huge_page_shift(h) == PMD_SHIFT;
> > +#else
> > +	return 0;
> > +#endif
> >  }
> >  
> >  static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
> > @@ -443,7 +446,6 @@ static inline pgoff_t basepage_index(struct page *page)
> >  	return page->index;
> >  }
> >  #define dissolve_free_huge_pages(s, e)	do {} while (0)
> > -#define pmd_huge_support()	0
> >  #define hugepage_migration_support(h)	0
> >  
> >  static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index ebe5880c29d6..1e22701c972b 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -264,6 +264,9 @@ config MIGRATION
> >  	  pages as migration can relocate pages to satisfy a huge page
> >  	  allocation instead of reclaiming.
> >  
> > +config ARCH_ENABLE_HUGEPAGE_MIGRATION
> > +	boolean
> > +
> 
> I don't remember how duplicated config entries work,
> so cannot comment on that.
> 
> >  config PHYS_ADDR_T_64BIT
> >  	def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
> >  
> > -- 
> > 1.9.3
> 
> --
> 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>
> 

--
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>

  reply	other threads:[~2014-05-30  2:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-28  8:32 BUG at mm/memory.c:1489! Michael Ellerman
2014-05-29  0:33 ` Hugh Dickins
2014-05-29  4:52   ` Naoya Horiguchi
2014-05-29 20:50     ` Hugh Dickins
2014-05-29  8:59   ` Michael Ellerman
2014-05-29 18:34     ` [PATCH] hugetlb: restrict hugepage_migration_support() to x86_64 (Re: BUG at mm/memory.c:1489!) Naoya Horiguchi
2014-05-29 22:04       ` Hugh Dickins
2014-05-30  2:56         ` Naoya Horiguchi [this message]
2014-05-29 21:03     ` BUG at mm/memory.c:1489! Hugh Dickins
     [not found]     ` <1401388474-mqnis5cp@n-horiguchi@ah.jp.nec.com>
2014-05-30  1:35       ` [PATCH] hugetlb: restrict hugepage_migration_support() to x86_64 (Re: BUG at mm/memory.c:1489!) Michael Ellerman
2014-05-30  1:52         ` Hugh Dickins
2014-05-30  3:04         ` Naoya Horiguchi
2014-05-30  4:13           ` [PATCH 1/2] hugetlb: restrict hugepage_migration_support() to x86_64 Naoya Horiguchi
2014-05-30 12:00             ` Hugh Dickins
2014-05-30  4:13           ` [PATCH 2/2] hugetlb: rename hugepage_migration_support() to ..._supported() Naoya Horiguchi
2014-05-30 12:02             ` Hugh Dickins

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=5387f356.c2ebc20a.19f7.63f7SMTPIN_ADDED_BROKEN@mx.google.com \
    --to=n-horiguchi@ah.jp.nec.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpe@ellerman.id.au \
    --cc=tony.luck@intel.com \
    --cc=trinity@vger.kernel.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