* [PATCH 0/3] Minor changes to common hugetlb code for ARM
@ 2012-09-11 16:47 Will Deacon
2012-09-11 16:47 ` [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() Will Deacon
` (3 more replies)
0 siblings, 4 replies; 27+ messages in thread
From: Will Deacon @ 2012-09-11 16:47 UTC (permalink / raw)
To: linux-mm; +Cc: linux-kernel, linux-arch, akpm, mhocko, Will Deacon
Hello,
A few changes are required to common hugetlb code before the ARM support
can be merged. I posted the main one previously, which has been picked up
by akpm:
http://marc.info/?l=linux-mm&m=134573987631394&w=2
The remaining three patches (included here) are all fairly minor but do
affect other architectures.
All comments welcome,
Will
Catalin Marinas (2):
mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear()
mm: thp: Fix the update_mmu_cache() last argument passing in
mm/huge_memory.c
Steve Capper (1):
mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE
arch/x86/Kconfig | 4 ++++
include/asm-generic/pgtable.h | 2 +-
mm/Kconfig | 2 +-
mm/huge_memory.c | 6 +++---
4 files changed, 9 insertions(+), 5 deletions(-)
--
1.7.4.1
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() 2012-09-11 16:47 [PATCH 0/3] Minor changes to common hugetlb code for ARM Will Deacon @ 2012-09-11 16:47 ` Will Deacon 2012-09-11 17:12 ` Kirill A. Shutemov 2012-09-12 15:30 ` Michal Hocko 2012-09-11 16:47 ` [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c Will Deacon ` (2 subsequent siblings) 3 siblings, 2 replies; 27+ messages in thread From: Will Deacon @ 2012-09-11 16:47 UTC (permalink / raw) To: linux-mm Cc: linux-kernel, linux-arch, akpm, mhocko, Catalin Marinas, Arnd Bergmann, Steve Capper, Will Deacon From: Catalin Marinas <catalin.marinas@arm.com> The CONFIG_TRANSPARENT_HUGEPAGE implementation of pmdp_get_and_clear() calls pmd_clear() with 3 arguments instead of 1. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> --- include/asm-generic/pgtable.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index ff4947b..f7e0206 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -87,7 +87,7 @@ static inline pmd_t pmdp_get_and_clear(struct mm_struct *mm, pmd_t *pmdp) { pmd_t pmd = *pmdp; - pmd_clear(mm, address, pmdp); + pmd_clear(pmdp); return pmd; } #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() 2012-09-11 16:47 ` [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() Will Deacon @ 2012-09-11 17:12 ` Kirill A. Shutemov 2012-09-12 15:30 ` Michal Hocko 1 sibling, 0 replies; 27+ messages in thread From: Kirill A. Shutemov @ 2012-09-11 17:12 UTC (permalink / raw) To: Will Deacon Cc: linux-mm, linux-kernel, linux-arch, akpm, mhocko, Catalin Marinas, Arnd Bergmann, Steve Capper On Tue, Sep 11, 2012 at 05:47:14PM +0100, Will Deacon wrote: > From: Catalin Marinas <catalin.marinas@arm.com> > > The CONFIG_TRANSPARENT_HUGEPAGE implementation of pmdp_get_and_clear() > calls pmd_clear() with 3 arguments instead of 1. > > Cc: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > Signed-off-by: Steve Capper <steve.capper@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> Reviewed-by: Kirill A. Shutemov <kirill@shutemov.name> > --- > include/asm-generic/pgtable.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > index ff4947b..f7e0206 100644 > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -87,7 +87,7 @@ static inline pmd_t pmdp_get_and_clear(struct mm_struct *mm, > pmd_t *pmdp) > { > pmd_t pmd = *pmdp; > - pmd_clear(mm, address, pmdp); > + pmd_clear(pmdp); > return pmd; > } > #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ > -- > 1.7.4.1 > > -- > 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> -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() 2012-09-11 16:47 ` [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() Will Deacon 2012-09-11 17:12 ` Kirill A. Shutemov @ 2012-09-12 15:30 ` Michal Hocko 1 sibling, 0 replies; 27+ messages in thread From: Michal Hocko @ 2012-09-12 15:30 UTC (permalink / raw) To: Will Deacon Cc: linux-mm, linux-kernel, linux-arch, akpm, Catalin Marinas, Arnd Bergmann, Steve Capper On Tue 11-09-12 17:47:14, Will Deacon wrote: > From: Catalin Marinas <catalin.marinas@arm.com> > > The CONFIG_TRANSPARENT_HUGEPAGE implementation of pmdp_get_and_clear() > calls pmd_clear() with 3 arguments instead of 1. only for !__HAVE_ARCH_PMDP_GET_AND_CLEAR which doesn't seem to happen because x86 defines this and it uses pmd_update. > > Cc: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > Signed-off-by: Steve Capper <steve.capper@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> Other than that it looks good. Reviewed-by: Michal Hocko <mhocko@suse.cz> > --- > include/asm-generic/pgtable.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h > index ff4947b..f7e0206 100644 > --- a/include/asm-generic/pgtable.h > +++ b/include/asm-generic/pgtable.h > @@ -87,7 +87,7 @@ static inline pmd_t pmdp_get_and_clear(struct mm_struct *mm, > pmd_t *pmdp) > { > pmd_t pmd = *pmdp; > - pmd_clear(mm, address, pmdp); > + pmd_clear(pmdp); > return pmd; > } > #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ > -- > 1.7.4.1 > -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-11 16:47 [PATCH 0/3] Minor changes to common hugetlb code for ARM Will Deacon 2012-09-11 16:47 ` [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() Will Deacon @ 2012-09-11 16:47 ` Will Deacon 2012-09-11 17:38 ` Kirill A. Shutemov ` (2 more replies) 2012-09-11 16:47 ` [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE Will Deacon 2012-09-12 15:27 ` [PATCH 0/3] Minor changes to common hugetlb code for ARM Michal Hocko 3 siblings, 3 replies; 27+ messages in thread From: Will Deacon @ 2012-09-11 16:47 UTC (permalink / raw) To: linux-mm Cc: linux-kernel, linux-arch, akpm, mhocko, Catalin Marinas, Steve Capper, Will Deacon From: Catalin Marinas <catalin.marinas@arm.com> The update_mmu_cache() takes a pointer (to pte_t by default) as the last argument but the huge_memory.c passes a pmd_t value. The patch changes the argument to the pmd_t * pointer. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> --- mm/huge_memory.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 57c4b93..4aa6d02 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -934,7 +934,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, entry = pmd_mkyoung(orig_pmd); entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); if (pmdp_set_access_flags(vma, haddr, pmd, entry, 1)) - update_mmu_cache(vma, address, entry); + update_mmu_cache(vma, address, pmd); ret |= VM_FAULT_WRITE; goto out_unlock; } @@ -986,7 +986,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, pmdp_clear_flush_notify(vma, haddr, pmd); page_add_new_anon_rmap(new_page, vma, haddr); set_pmd_at(mm, haddr, pmd, entry); - update_mmu_cache(vma, address, entry); + update_mmu_cache(vma, address, pmd); page_remove_rmap(page); put_page(page); ret |= VM_FAULT_WRITE; @@ -1989,7 +1989,7 @@ static void collapse_huge_page(struct mm_struct *mm, BUG_ON(!pmd_none(*pmd)); page_add_new_anon_rmap(new_page, vma, address); set_pmd_at(mm, address, pmd, _pmd); - update_mmu_cache(vma, address, _pmd); + update_mmu_cache(vma, address, pmd); prepare_pmd_huge_pte(pgtable, mm); spin_unlock(&mm->page_table_lock); -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-11 16:47 ` [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c Will Deacon @ 2012-09-11 17:38 ` Kirill A. Shutemov 2012-09-12 15:40 ` Michal Hocko 2012-09-15 13:38 ` Ralf Baechle 2 siblings, 0 replies; 27+ messages in thread From: Kirill A. Shutemov @ 2012-09-11 17:38 UTC (permalink / raw) To: Will Deacon Cc: linux-mm, linux-kernel, linux-arch, akpm, mhocko, Catalin Marinas, Steve Capper On Tue, Sep 11, 2012 at 05:47:15PM +0100, Will Deacon wrote: > From: Catalin Marinas <catalin.marinas@arm.com> > > The update_mmu_cache() takes a pointer (to pte_t by default) as the last > argument but the huge_memory.c passes a pmd_t value. The patch changes > the argument to the pmd_t * pointer. > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > Signed-off-by: Steve Capper <steve.capper@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> Reviewed-by: Kirill A. Shutemov <kirill@shutemov.name> > --- > mm/huge_memory.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 57c4b93..4aa6d02 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -934,7 +934,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, > entry = pmd_mkyoung(orig_pmd); > entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); > if (pmdp_set_access_flags(vma, haddr, pmd, entry, 1)) > - update_mmu_cache(vma, address, entry); > + update_mmu_cache(vma, address, pmd); > ret |= VM_FAULT_WRITE; > goto out_unlock; > } > @@ -986,7 +986,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, > pmdp_clear_flush_notify(vma, haddr, pmd); > page_add_new_anon_rmap(new_page, vma, haddr); > set_pmd_at(mm, haddr, pmd, entry); > - update_mmu_cache(vma, address, entry); > + update_mmu_cache(vma, address, pmd); > page_remove_rmap(page); > put_page(page); > ret |= VM_FAULT_WRITE; > @@ -1989,7 +1989,7 @@ static void collapse_huge_page(struct mm_struct *mm, > BUG_ON(!pmd_none(*pmd)); > page_add_new_anon_rmap(new_page, vma, address); > set_pmd_at(mm, address, pmd, _pmd); > - update_mmu_cache(vma, address, _pmd); > + update_mmu_cache(vma, address, pmd); > prepare_pmd_huge_pte(pgtable, mm); > spin_unlock(&mm->page_table_lock); > > -- > 1.7.4.1 > > -- > 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> -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-11 16:47 ` [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c Will Deacon 2012-09-11 17:38 ` Kirill A. Shutemov @ 2012-09-12 15:40 ` Michal Hocko 2012-09-12 15:51 ` Catalin Marinas 2012-09-15 13:38 ` Ralf Baechle 2 siblings, 1 reply; 27+ messages in thread From: Michal Hocko @ 2012-09-12 15:40 UTC (permalink / raw) To: Will Deacon Cc: linux-mm, linux-kernel, linux-arch, akpm, Catalin Marinas, Steve Capper On Tue 11-09-12 17:47:15, Will Deacon wrote: > From: Catalin Marinas <catalin.marinas@arm.com> > > The update_mmu_cache() takes a pointer (to pte_t by default) as the last > argument but the huge_memory.c passes a pmd_t value. The patch changes > the argument to the pmd_t * pointer. > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > Signed-off-by: Steve Capper <steve.capper@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> > --- > mm/huge_memory.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 57c4b93..4aa6d02 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -934,7 +934,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, > entry = pmd_mkyoung(orig_pmd); > entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); > if (pmdp_set_access_flags(vma, haddr, pmd, entry, 1)) > - update_mmu_cache(vma, address, entry); > + update_mmu_cache(vma, address, pmd); I am not sure but shouldn't we use the new entry rather than the given pmd? > ret |= VM_FAULT_WRITE; > goto out_unlock; > } > @@ -986,7 +986,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, > pmdp_clear_flush_notify(vma, haddr, pmd); > page_add_new_anon_rmap(new_page, vma, haddr); > set_pmd_at(mm, haddr, pmd, entry); > - update_mmu_cache(vma, address, entry); > + update_mmu_cache(vma, address, pmd); > page_remove_rmap(page); > put_page(page); > ret |= VM_FAULT_WRITE; > @@ -1989,7 +1989,7 @@ static void collapse_huge_page(struct mm_struct *mm, > BUG_ON(!pmd_none(*pmd)); > page_add_new_anon_rmap(new_page, vma, address); > set_pmd_at(mm, address, pmd, _pmd); > - update_mmu_cache(vma, address, _pmd); > + update_mmu_cache(vma, address, pmd); > prepare_pmd_huge_pte(pgtable, mm); > spin_unlock(&mm->page_table_lock); > > -- > 1.7.4.1 > -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-12 15:40 ` Michal Hocko @ 2012-09-12 15:51 ` Catalin Marinas 0 siblings, 0 replies; 27+ messages in thread From: Catalin Marinas @ 2012-09-12 15:51 UTC (permalink / raw) To: Michal Hocko Cc: Will Deacon, linux-mm, linux-kernel, linux-arch, akpm, Steve Capper On Wed, Sep 12, 2012 at 04:40:37PM +0100, Michal Hocko wrote: > On Tue 11-09-12 17:47:15, Will Deacon wrote: > > From: Catalin Marinas <catalin.marinas@arm.com> > > > > The update_mmu_cache() takes a pointer (to pte_t by default) as the last > > argument but the huge_memory.c passes a pmd_t value. The patch changes > > the argument to the pmd_t * pointer. > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > > Signed-off-by: Steve Capper <steve.capper@arm.com> > > Signed-off-by: Will Deacon <will.deacon@arm.com> > > --- > > mm/huge_memory.c | 6 +++--- > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 57c4b93..4aa6d02 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -934,7 +934,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, > > entry = pmd_mkyoung(orig_pmd); > > entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); > > if (pmdp_set_access_flags(vma, haddr, pmd, entry, 1)) > > - update_mmu_cache(vma, address, entry); > > + update_mmu_cache(vma, address, pmd); > > I am not sure but shouldn't we use the new entry rather than the given > pmd? The pmd pointer is the new pmd and 'entry' is the new value derived from orig_pmd. update_mmu_cache() expects a pointer to pte_t or pmd_t rather than it's value. -- Catalin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-11 16:47 ` [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c Will Deacon 2012-09-11 17:38 ` Kirill A. Shutemov 2012-09-12 15:40 ` Michal Hocko @ 2012-09-15 13:38 ` Ralf Baechle 2012-09-18 19:33 ` Andrew Morton 2 siblings, 1 reply; 27+ messages in thread From: Ralf Baechle @ 2012-09-15 13:38 UTC (permalink / raw) To: Will Deacon Cc: linux-mm, linux-kernel, linux-arch, akpm, mhocko, Catalin Marinas, Steve Capper On Tue, Sep 11, 2012 at 05:47:15PM +0100, Will Deacon wrote: > The update_mmu_cache() takes a pointer (to pte_t by default) as the last > argument but the huge_memory.c passes a pmd_t value. The patch changes > the argument to the pmd_t * pointer. > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > Signed-off-by: Steve Capper <steve.capper@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> > --- > mm/huge_memory.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 57c4b93..4aa6d02 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -934,7 +934,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, > entry = pmd_mkyoung(orig_pmd); > entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); > if (pmdp_set_access_flags(vma, haddr, pmd, entry, 1)) > - update_mmu_cache(vma, address, entry); > + update_mmu_cache(vma, address, pmd); Documentation/cachetlb.txt will need an update as well. Currently it says: 5) void update_mmu_cache(struct vm_area_struct *vma, unsigned long address, pte_t *ptep) I would prefer we introduce something like update_mmu_cache_huge_page(vma, address, pmd) and leave the classic update_mmu_cache() unchanged. Ralf ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-15 13:38 ` Ralf Baechle @ 2012-09-18 19:33 ` Andrew Morton 2012-09-19 9:12 ` Catalin Marinas 0 siblings, 1 reply; 27+ messages in thread From: Andrew Morton @ 2012-09-18 19:33 UTC (permalink / raw) To: Ralf Baechle Cc: Will Deacon, linux-mm, linux-kernel, linux-arch, mhocko, Catalin Marinas, Steve Capper On Sat, 15 Sep 2012 15:38:33 +0200 Ralf Baechle <ralf@linux-mips.org> wrote: > On Tue, Sep 11, 2012 at 05:47:15PM +0100, Will Deacon wrote: > > > The update_mmu_cache() takes a pointer (to pte_t by default) as the last > > argument but the huge_memory.c passes a pmd_t value. The patch changes > > the argument to the pmd_t * pointer. > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > > Signed-off-by: Steve Capper <steve.capper@arm.com> > > Signed-off-by: Will Deacon <will.deacon@arm.com> > > --- > > mm/huge_memory.c | 6 +++--- > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 57c4b93..4aa6d02 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -934,7 +934,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, > > entry = pmd_mkyoung(orig_pmd); > > entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); > > if (pmdp_set_access_flags(vma, haddr, pmd, entry, 1)) > > - update_mmu_cache(vma, address, entry); > > + update_mmu_cache(vma, address, pmd); > > Documentation/cachetlb.txt will need an update as well. Currently it says: > > 5) void update_mmu_cache(struct vm_area_struct *vma, > unsigned long address, pte_t *ptep) Yes please. > I would prefer we introduce something like update_mmu_cache_huge_page(vma, > address, pmd) and leave the classic update_mmu_cache() unchanged. Why? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-18 19:33 ` Andrew Morton @ 2012-09-19 9:12 ` Catalin Marinas 2012-09-19 15:53 ` Ralf Baechle 0 siblings, 1 reply; 27+ messages in thread From: Catalin Marinas @ 2012-09-19 9:12 UTC (permalink / raw) To: Andrew Morton Cc: Ralf Baechle, Will Deacon, linux-mm, linux-kernel, linux-arch, mhocko, Steve Capper On 18 September 2012 20:33, Andrew Morton <akpm@linux-foundation.org> wrote: > On Sat, 15 Sep 2012 15:38:33 +0200 > Ralf Baechle <ralf@linux-mips.org> wrote: >> On Tue, Sep 11, 2012 at 05:47:15PM +0100, Will Deacon wrote: >> > The update_mmu_cache() takes a pointer (to pte_t by default) as the last >> > argument but the huge_memory.c passes a pmd_t value. The patch changes >> > the argument to the pmd_t * pointer. >> > >> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> >> > Signed-off-by: Steve Capper <steve.capper@arm.com> >> > Signed-off-by: Will Deacon <will.deacon@arm.com> >> > --- >> > mm/huge_memory.c | 6 +++--- >> > 1 files changed, 3 insertions(+), 3 deletions(-) >> > >> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c >> > index 57c4b93..4aa6d02 100644 >> > --- a/mm/huge_memory.c >> > +++ b/mm/huge_memory.c >> > @@ -934,7 +934,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, >> > entry = pmd_mkyoung(orig_pmd); >> > entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); >> > if (pmdp_set_access_flags(vma, haddr, pmd, entry, 1)) >> > - update_mmu_cache(vma, address, entry); >> > + update_mmu_cache(vma, address, pmd); >> >> Documentation/cachetlb.txt will need an update as well. Currently it says: >> >> 5) void update_mmu_cache(struct vm_area_struct *vma, >> unsigned long address, pte_t *ptep) > > Yes please. Should we just use a generic (void *) for the last argument or force a cast in mm/huge_memory.c? Ralf's point is that transparent huge page code calls update_mmu_cache with a (pmd_t *) as the last argument. This could make sense for THP as it assumes that huge pages can only be created at the pmd level. But that's unlike mm/hugetlb.c which casts huge page types to pte_t, even though on ARM they are implemented at the pmd level. On ARM (with VIPT caches) update_mmu_cache() is empty like on x86, though a static inline rather than macro. -- Catalin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-19 9:12 ` Catalin Marinas @ 2012-09-19 15:53 ` Ralf Baechle 2012-09-20 12:44 ` Will Deacon 0 siblings, 1 reply; 27+ messages in thread From: Ralf Baechle @ 2012-09-19 15:53 UTC (permalink / raw) To: Catalin Marinas Cc: Andrew Morton, Will Deacon, linux-mm, linux-kernel, linux-arch, mhocko, Steve Capper On Wed, Sep 19, 2012 at 10:12:28AM +0100, Catalin Marinas wrote: > >> 5) void update_mmu_cache(struct vm_area_struct *vma, > >> unsigned long address, pte_t *ptep) > > > > Yes please. > > Should we just use a generic (void *) for the last argument or force a > cast in mm/huge_memory.c? > > Ralf's point is that transparent huge page code calls update_mmu_cache > with a (pmd_t *) as the last argument. This could make sense for THP > as it assumes that huge pages can only be created at the pmd level. > But that's unlike mm/hugetlb.c which casts huge page types to pte_t, > even though on ARM they are implemented at the pmd level. > > On ARM (with VIPT caches) update_mmu_cache() is empty like on x86, > though a static inline rather than macro. It's even worse - mm/huge_memory.c is passing a pmd_t, not a pointer so changing the type of update_mmu_cache's 3rd argument alone won't cut it. This went unnoticed so far because all existing architectures supporting transparent huge pages implement update_mmu_cache() as do { } while (0). MIPS uses update_mmu_cache() as the hook to deal with cache aliases and pre-faulting a TLB entry. But aliases don't affect small pages and having a separate variant of update_mmu_cache for huge pages will allow some other optimizations. That's minor but it's the argument types that really need to be fixed and because MIPS also implements huge pages at PMD level I'd be happy if we settle on pte_t * for mm/huge_memory.c. Ralf ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-19 15:53 ` Ralf Baechle @ 2012-09-20 12:44 ` Will Deacon 2012-09-20 19:32 ` David Miller 0 siblings, 1 reply; 27+ messages in thread From: Will Deacon @ 2012-09-20 12:44 UTC (permalink / raw) To: Ralf Baechle Cc: Catalin Marinas, Andrew Morton, linux-mm, linux-kernel, linux-arch, mhocko, Steve Capper Hi Ralf, On Wed, Sep 19, 2012 at 04:53:46PM +0100, Ralf Baechle wrote: > On Wed, Sep 19, 2012 at 10:12:28AM +0100, Catalin Marinas wrote: > > > >> 5) void update_mmu_cache(struct vm_area_struct *vma, > > >> unsigned long address, pte_t *ptep) > > > > > > Yes please. > > > > Should we just use a generic (void *) for the last argument or force a > > cast in mm/huge_memory.c? > > > > Ralf's point is that transparent huge page code calls update_mmu_cache > > with a (pmd_t *) as the last argument. This could make sense for THP > > as it assumes that huge pages can only be created at the pmd level. > > But that's unlike mm/hugetlb.c which casts huge page types to pte_t, > > even though on ARM they are implemented at the pmd level. > > > > On ARM (with VIPT caches) update_mmu_cache() is empty like on x86, > > though a static inline rather than macro. > > It's even worse - mm/huge_memory.c is passing a pmd_t, not a pointer so > changing the type of update_mmu_cache's 3rd argument alone won't cut it. > > This went unnoticed so far because all existing architectures supporting > transparent huge pages implement update_mmu_cache() as do { } while (0). > > MIPS uses update_mmu_cache() as the hook to deal with cache aliases and > pre-faulting a TLB entry. But aliases don't affect small pages and having > a separate variant of update_mmu_cache for huge pages will allow some other > optimizations. That's minor but it's the argument types that really need > to be fixed and because MIPS also implements huge pages at PMD level I'd > be happy if we settle on pte_t * for mm/huge_memory.c. Just to clarify: do you want a cast from pmd_t * to pte_t * or instead copy the hugetlb code and pass ptes around instead of pmds? The latter is pretty invasive... Will ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c 2012-09-20 12:44 ` Will Deacon @ 2012-09-20 19:32 ` David Miller 0 siblings, 0 replies; 27+ messages in thread From: David Miller @ 2012-09-20 19:32 UTC (permalink / raw) To: will.deacon Cc: ralf, Catalin.Marinas, akpm, linux-mm, linux-kernel, linux-arch, mhocko, Steve.Capper From: Will Deacon <will.deacon@arm.com> Date: Thu, 20 Sep 2012 13:44:01 +0100 > Just to clarify: do you want a cast from pmd_t * to pte_t * or instead copy > the hugetlb code and pass ptes around instead of pmds? The latter is pretty > invasive... But will be necessary for SPARC64 and POWERPC where the hugetlb entries are encoded at the PTE level. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE 2012-09-11 16:47 [PATCH 0/3] Minor changes to common hugetlb code for ARM Will Deacon 2012-09-11 16:47 ` [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() Will Deacon 2012-09-11 16:47 ` [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c Will Deacon @ 2012-09-11 16:47 ` Will Deacon 2012-09-11 17:41 ` Kirill A. Shutemov ` (2 more replies) 2012-09-12 15:27 ` [PATCH 0/3] Minor changes to common hugetlb code for ARM Michal Hocko 3 siblings, 3 replies; 27+ messages in thread From: Will Deacon @ 2012-09-11 16:47 UTC (permalink / raw) To: linux-mm Cc: linux-kernel, linux-arch, akpm, mhocko, Steve Capper, Will Deacon From: Steve Capper <steve.capper@arm.com> Different architectures have slightly different pre-requisites for supporting Transparent Huge Pages. To simplify the layout of mm/Kconfig, a new option HAVE_ARCH_TRANSPARENT_HUGEPAGE is introduced and set in each architecture's Kconfig file (at the moment x86, with ARM being set in a future patch). Signed-off-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> --- arch/x86/Kconfig | 4 ++++ mm/Kconfig | 2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 8ec3a1a..7decdcf 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1297,6 +1297,10 @@ config ILLEGAL_POINTER_VALUE default 0 if X86_32 default 0xdead000000000000 if X86_64 +config HAVE_ARCH_TRANSPARENT_HUGEPAGE + def_bool y + depends on MMU + source "mm/Kconfig" config HIGHPTE diff --git a/mm/Kconfig b/mm/Kconfig index d5c8019..3322342 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -318,7 +318,7 @@ config NOMMU_INITIAL_TRIM_EXCESS config TRANSPARENT_HUGEPAGE bool "Transparent Hugepage Support" - depends on X86 && MMU + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE select COMPACTION help Transparent Hugepages allows the kernel to use huge pages and -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE 2012-09-11 16:47 ` [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE Will Deacon @ 2012-09-11 17:41 ` Kirill A. Shutemov 2012-09-12 15:32 ` Michal Hocko 2012-09-13 19:05 ` Andrew Morton 2 siblings, 0 replies; 27+ messages in thread From: Kirill A. Shutemov @ 2012-09-11 17:41 UTC (permalink / raw) To: Will Deacon Cc: linux-mm, linux-kernel, linux-arch, akpm, mhocko, Steve Capper On Tue, Sep 11, 2012 at 05:47:16PM +0100, Will Deacon wrote: > From: Steve Capper <steve.capper@arm.com> > > Different architectures have slightly different pre-requisites for supporting > Transparent Huge Pages. To simplify the layout of mm/Kconfig, a new option > HAVE_ARCH_TRANSPARENT_HUGEPAGE is introduced and set in each architecture's > Kconfig file (at the moment x86, with ARM being set in a future patch). > > Signed-off-by: Steve Capper <steve.capper@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> Reviewed-by: Kirill A. Shutemov <kirill@shutemov.name> > --- > arch/x86/Kconfig | 4 ++++ > mm/Kconfig | 2 +- > 2 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 8ec3a1a..7decdcf 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1297,6 +1297,10 @@ config ILLEGAL_POINTER_VALUE > default 0 if X86_32 > default 0xdead000000000000 if X86_64 > > +config HAVE_ARCH_TRANSPARENT_HUGEPAGE > + def_bool y > + depends on MMU > + > source "mm/Kconfig" > > config HIGHPTE > diff --git a/mm/Kconfig b/mm/Kconfig > index d5c8019..3322342 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -318,7 +318,7 @@ config NOMMU_INITIAL_TRIM_EXCESS > > config TRANSPARENT_HUGEPAGE > bool "Transparent Hugepage Support" > - depends on X86 && MMU > + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE > select COMPACTION > help > Transparent Hugepages allows the kernel to use huge pages and > -- > 1.7.4.1 > > -- > 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> -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE 2012-09-11 16:47 ` [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE Will Deacon 2012-09-11 17:41 ` Kirill A. Shutemov @ 2012-09-12 15:32 ` Michal Hocko 2012-09-12 18:06 ` Chris Metcalf 2012-09-13 19:05 ` Andrew Morton 2 siblings, 1 reply; 27+ messages in thread From: Michal Hocko @ 2012-09-12 15:32 UTC (permalink / raw) To: Will Deacon; +Cc: linux-mm, linux-kernel, linux-arch, akpm, Steve Capper On Tue 11-09-12 17:47:16, Will Deacon wrote: > From: Steve Capper <steve.capper@arm.com> > > Different architectures have slightly different pre-requisites for supporting > Transparent Huge Pages. To simplify the layout of mm/Kconfig, a new option > HAVE_ARCH_TRANSPARENT_HUGEPAGE is introduced and set in each architecture's > Kconfig file (at the moment x86, with ARM being set in a future patch). > > Signed-off-by: Steve Capper <steve.capper@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> Makes sense if there are going to be more archs to support THP. Reviewed-by: Michal Hocko <mhocko@suse.cz> > --- > arch/x86/Kconfig | 4 ++++ > mm/Kconfig | 2 +- > 2 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 8ec3a1a..7decdcf 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1297,6 +1297,10 @@ config ILLEGAL_POINTER_VALUE > default 0 if X86_32 > default 0xdead000000000000 if X86_64 > > +config HAVE_ARCH_TRANSPARENT_HUGEPAGE > + def_bool y > + depends on MMU > + > source "mm/Kconfig" > > config HIGHPTE > diff --git a/mm/Kconfig b/mm/Kconfig > index d5c8019..3322342 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -318,7 +318,7 @@ config NOMMU_INITIAL_TRIM_EXCESS > > config TRANSPARENT_HUGEPAGE > bool "Transparent Hugepage Support" > - depends on X86 && MMU > + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE > select COMPACTION > help > Transparent Hugepages allows the kernel to use huge pages and > -- > 1.7.4.1 > -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE 2012-09-12 15:32 ` Michal Hocko @ 2012-09-12 18:06 ` Chris Metcalf 2012-09-12 18:10 ` Will Deacon 0 siblings, 1 reply; 27+ messages in thread From: Chris Metcalf @ 2012-09-12 18:06 UTC (permalink / raw) To: Michal Hocko Cc: Will Deacon, linux-mm, linux-kernel, linux-arch, akpm, Steve Capper On 9/12/2012 11:32 AM, Michal Hocko wrote: > Makes sense if there are going to be more archs to support THP. The tile architecture currently supports it in our in-house tree, though we haven't returned it to the community yet. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE 2012-09-12 18:06 ` Chris Metcalf @ 2012-09-12 18:10 ` Will Deacon 0 siblings, 0 replies; 27+ messages in thread From: Will Deacon @ 2012-09-12 18:10 UTC (permalink / raw) To: Chris Metcalf Cc: Michal Hocko, linux-mm, linux-kernel, linux-arch, akpm, Steve Capper On Wed, Sep 12, 2012 at 07:06:43PM +0100, Chris Metcalf wrote: > On 9/12/2012 11:32 AM, Michal Hocko wrote: > > Makes sense if there are going to be more archs to support THP. > > The tile architecture currently supports it in our in-house tree, > though we haven't returned it to the community yet. That's a similar situation for AArch64. We hope to post the arm patches pretty soon though, just ironing out some issues with the thp code. Unfortunately, it looks like there might be one more change to the core code as we don't have hardware page aging and need to manipulate the YOUNG bit explicitly. Will ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE 2012-09-11 16:47 ` [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE Will Deacon 2012-09-11 17:41 ` Kirill A. Shutemov 2012-09-12 15:32 ` Michal Hocko @ 2012-09-13 19:05 ` Andrew Morton 2012-09-13 21:26 ` Will Deacon 2012-09-13 21:27 ` Stephen Rothwell 2 siblings, 2 replies; 27+ messages in thread From: Andrew Morton @ 2012-09-13 19:05 UTC (permalink / raw) To: Will Deacon Cc: linux-mm, linux-kernel, linux-arch, mhocko, Steve Capper, Gerald Schaefer On Tue, 11 Sep 2012 17:47:16 +0100 Will Deacon <will.deacon@arm.com> wrote: > From: Steve Capper <steve.capper@arm.com> > > Different architectures have slightly different pre-requisites for supporting > Transparent Huge Pages. To simplify the layout of mm/Kconfig, a new option > HAVE_ARCH_TRANSPARENT_HUGEPAGE is introduced and set in each architecture's > Kconfig file (at the moment x86, with ARM being set in a future patch). > > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1297,6 +1297,10 @@ config ILLEGAL_POINTER_VALUE > default 0 if X86_32 > default 0xdead000000000000 if X86_64 > > +config HAVE_ARCH_TRANSPARENT_HUGEPAGE > + def_bool y > + depends on MMU > + > source "mm/Kconfig" > > config HIGHPTE > diff --git a/mm/Kconfig b/mm/Kconfig > index d5c8019..3322342 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -318,7 +318,7 @@ config NOMMU_INITIAL_TRIM_EXCESS > > config TRANSPARENT_HUGEPAGE > bool "Transparent Hugepage Support" > - depends on X86 && MMU > + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE > select COMPACTION > help > Transparent Hugepages allows the kernel to use huge pages and We need to talk with Gerald concerning http://ozlabs.org/~akpm/mmotm/broken-out/thp-x86-introduce-have_arch_transparent_hugepage.patch I did this. Please check. From: Steve Capper <steve.capper@arm.com> Subject: mm: introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE Different architectures have slightly different pre-requisites for supporting Transparent Huge Pages. To simplify the layout of mm/Kconfig, a new option HAVE_ARCH_TRANSPARENT_HUGEPAGE is introduced and set in each architecture's Kconfig file (at the moment x86, with ARM being set in a future patch). Signed-off-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Cc: Michal Hocko <mhocko@suse.cz> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- arch/x86/Kconfig | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff -puN arch/x86/Kconfig~mm-introduce-have_arch_transparent_hugepage arch/x86/Kconfig --- a/arch/x86/Kconfig~mm-introduce-have_arch_transparent_hugepage +++ a/arch/x86/Kconfig @@ -83,7 +83,6 @@ config X86 select IRQ_FORCED_THREADING select USE_GENERIC_SMP_HELPERS if SMP select HAVE_BPF_JIT if X86_64 - select HAVE_ARCH_TRANSPARENT_HUGEPAGE select CLKEVT_I8253 select ARCH_HAVE_NMI_SAFE_CMPXCHG select GENERIC_IOMAP @@ -1330,6 +1329,10 @@ config ILLEGAL_POINTER_VALUE default 0 if X86_32 default 0xdead000000000000 if X86_64 +config HAVE_ARCH_TRANSPARENT_HUGEPAGE + def_bool y + depends on MMU + source "mm/Kconfig" config HIGHPTE ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE 2012-09-13 19:05 ` Andrew Morton @ 2012-09-13 21:26 ` Will Deacon 2012-09-13 21:27 ` Stephen Rothwell 1 sibling, 0 replies; 27+ messages in thread From: Will Deacon @ 2012-09-13 21:26 UTC (permalink / raw) To: Andrew Morton Cc: linux-mm, linux-kernel, linux-arch, mhocko, Steve Capper, Gerald Schaefer Hi Andrew, On Thu, Sep 13, 2012 at 08:05:14PM +0100, Andrew Morton wrote: > On Tue, 11 Sep 2012 17:47:16 +0100 > Will Deacon <will.deacon@arm.com> wrote: > > diff --git a/mm/Kconfig b/mm/Kconfig > > index d5c8019..3322342 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -318,7 +318,7 @@ config NOMMU_INITIAL_TRIM_EXCESS > > > > config TRANSPARENT_HUGEPAGE > > bool "Transparent Hugepage Support" > > - depends on X86 && MMU > > + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE > > select COMPACTION > > help > > Transparent Hugepages allows the kernel to use huge pages and > > We need to talk with Gerald concerning > http://ozlabs.org/~akpm/mmotm/broken-out/thp-x86-introduce-have_arch_transparent_hugepage.patch > > > I did this. Please check. [...] We missed Gerald's patch for s390 and, having picked it into our tree, it acts as a drop-in replacement for what we came up with. So I think you can just drop our patch ("mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE") altogether. Cheers, Will ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE 2012-09-13 19:05 ` Andrew Morton 2012-09-13 21:26 ` Will Deacon @ 2012-09-13 21:27 ` Stephen Rothwell 2012-09-13 21:40 ` Andrew Morton 1 sibling, 1 reply; 27+ messages in thread From: Stephen Rothwell @ 2012-09-13 21:27 UTC (permalink / raw) To: Andrew Morton Cc: Will Deacon, linux-mm, linux-kernel, linux-arch, mhocko, Steve Capper, Gerald Schaefer [-- Attachment #1: Type: text/plain, Size: 968 bytes --] Hi Andrew, On Thu, 13 Sep 2012 12:05:14 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > diff -puN arch/x86/Kconfig~mm-introduce-have_arch_transparent_hugepage arch/x86/Kconfig > --- a/arch/x86/Kconfig~mm-introduce-have_arch_transparent_hugepage > +++ a/arch/x86/Kconfig > @@ -83,7 +83,6 @@ config X86 > select IRQ_FORCED_THREADING > select USE_GENERIC_SMP_HELPERS if SMP > select HAVE_BPF_JIT if X86_64 > - select HAVE_ARCH_TRANSPARENT_HUGEPAGE Why not select HAVE_ARCH_TRANSPARENT_HUGEPAGE if MMU > select CLKEVT_I8253 > select ARCH_HAVE_NMI_SAFE_CMPXCHG > select GENERIC_IOMAP > @@ -1330,6 +1329,10 @@ config ILLEGAL_POINTER_VALUE > default 0 if X86_32 > default 0xdead000000000000 if X86_64 > > +config HAVE_ARCH_TRANSPARENT_HUGEPAGE > + def_bool y > + depends on MMU > + -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE 2012-09-13 21:27 ` Stephen Rothwell @ 2012-09-13 21:40 ` Andrew Morton 0 siblings, 0 replies; 27+ messages in thread From: Andrew Morton @ 2012-09-13 21:40 UTC (permalink / raw) To: Stephen Rothwell Cc: Will Deacon, linux-mm, linux-kernel, linux-arch, mhocko, Steve Capper, Gerald Schaefer On Fri, 14 Sep 2012 07:27:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi Andrew, > > On Thu, 13 Sep 2012 12:05:14 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > > > diff -puN arch/x86/Kconfig~mm-introduce-have_arch_transparent_hugepage arch/x86/Kconfig > > --- a/arch/x86/Kconfig~mm-introduce-have_arch_transparent_hugepage > > +++ a/arch/x86/Kconfig > > @@ -83,7 +83,6 @@ config X86 > > select IRQ_FORCED_THREADING > > select USE_GENERIC_SMP_HELPERS if SMP > > select HAVE_BPF_JIT if X86_64 > > - select HAVE_ARCH_TRANSPARENT_HUGEPAGE > > Why not > select HAVE_ARCH_TRANSPARENT_HUGEPAGE if MMU > Well, this is in arch/x86/Kconfig, where MMU is known to always be set. Yes, I think Gerald's patch will suffice: --- a/arch/Kconfig~thp-x86-introduce-have_arch_transparent_hugepage +++ a/arch/Kconfig @@ -326,4 +326,7 @@ config HAVE_RCU_USER_QS are already protected inside rcu_irq_enter/rcu_irq_exit() but preemption or signal handling on irq exit still need to be protected. +config HAVE_ARCH_TRANSPARENT_HUGEPAGE + bool + source "kernel/gcov/Kconfig" --- a/arch/x86/Kconfig~thp-x86-introduce-have_arch_transparent_hugepage +++ a/arch/x86/Kconfig @@ -83,6 +83,7 @@ config X86 select IRQ_FORCED_THREADING select USE_GENERIC_SMP_HELPERS if SMP select HAVE_BPF_JIT if X86_64 + select HAVE_ARCH_TRANSPARENT_HUGEPAGE select CLKEVT_I8253 select ARCH_HAVE_NMI_SAFE_CMPXCHG select GENERIC_IOMAP --- a/mm/Kconfig~thp-x86-introduce-have_arch_transparent_hugepage +++ a/mm/Kconfig @@ -318,7 +318,7 @@ config NOMMU_INITIAL_TRIM_EXCESS config TRANSPARENT_HUGEPAGE bool "Transparent Hugepage Support" - depends on X86 && MMU + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE select COMPACTION help Transparent Hugepages allows the kernel to use huge pages and _ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/3] Minor changes to common hugetlb code for ARM 2012-09-11 16:47 [PATCH 0/3] Minor changes to common hugetlb code for ARM Will Deacon ` (2 preceding siblings ...) 2012-09-11 16:47 ` [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE Will Deacon @ 2012-09-12 15:27 ` Michal Hocko 2012-09-12 15:55 ` Will Deacon 2012-09-13 0:12 ` Andrea Arcangeli 3 siblings, 2 replies; 27+ messages in thread From: Michal Hocko @ 2012-09-12 15:27 UTC (permalink / raw) To: Will Deacon; +Cc: linux-mm, linux-kernel, linux-arch, akpm, Andrea Arcangeli On Tue 11-09-12 17:47:13, Will Deacon wrote: > Hello, Hi, > A few changes are required to common hugetlb code before the ARM support > can be merged. I posted the main one previously, which has been picked up > by akpm: > > http://marc.info/?l=linux-mm&m=134573987631394&w=2 > > The remaining three patches (included here) are all fairly minor but do > affect other architectures. I am quite confused. Why THP changes are required for hugetlb code for ARM? Besides that I would suggest adding Andrea to the CC (added now the whole series can be found here http://lkml.org/lkml/2012/9/11/322) list for all THP changes. > > All comments welcome, > > Will > > Catalin Marinas (2): > mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() > mm: thp: Fix the update_mmu_cache() last argument passing in > mm/huge_memory.c > > Steve Capper (1): > mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE > > arch/x86/Kconfig | 4 ++++ > include/asm-generic/pgtable.h | 2 +- > mm/Kconfig | 2 +- > mm/huge_memory.c | 6 +++--- > 4 files changed, 9 insertions(+), 5 deletions(-) > > -- > 1.7.4.1 > -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/3] Minor changes to common hugetlb code for ARM 2012-09-12 15:27 ` [PATCH 0/3] Minor changes to common hugetlb code for ARM Michal Hocko @ 2012-09-12 15:55 ` Will Deacon 2012-09-13 12:22 ` Michal Hocko 2012-09-13 0:12 ` Andrea Arcangeli 1 sibling, 1 reply; 27+ messages in thread From: Will Deacon @ 2012-09-12 15:55 UTC (permalink / raw) To: Michal Hocko; +Cc: linux-mm, linux-kernel, linux-arch, akpm, Andrea Arcangeli On Wed, Sep 12, 2012 at 04:27:59PM +0100, Michal Hocko wrote: > On Tue 11-09-12 17:47:13, Will Deacon wrote: > > A few changes are required to common hugetlb code before the ARM support > > can be merged. I posted the main one previously, which has been picked up > > by akpm: > > > > http://marc.info/?l=linux-mm&m=134573987631394&w=2 > > > > The remaining three patches (included here) are all fairly minor but do > > affect other architectures. > > I am quite confused. Why THP changes are required for hugetlb code for > ARM? Sorry, I was being too vague. We add ARM support for THP in the same patch series as hugetlb, so I was loosely referring to that lot. > Besides that I would suggest adding Andrea to the CC (added now the > whole series can be found here http://lkml.org/lkml/2012/9/11/322) list > for all THP changes. Thanks for that, I'll add Andrew to future submissions. Will ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/3] Minor changes to common hugetlb code for ARM 2012-09-12 15:55 ` Will Deacon @ 2012-09-13 12:22 ` Michal Hocko 0 siblings, 0 replies; 27+ messages in thread From: Michal Hocko @ 2012-09-13 12:22 UTC (permalink / raw) To: Will Deacon; +Cc: linux-mm, linux-kernel, linux-arch, akpm, Andrea Arcangeli On Wed 12-09-12 16:55:55, Will Deacon wrote: > On Wed, Sep 12, 2012 at 04:27:59PM +0100, Michal Hocko wrote: > > On Tue 11-09-12 17:47:13, Will Deacon wrote: > > > A few changes are required to common hugetlb code before the ARM support > > > can be merged. I posted the main one previously, which has been picked up > > > by akpm: > > > > > > http://marc.info/?l=linux-mm&m=134573987631394&w=2 > > > > > > The remaining three patches (included here) are all fairly minor but do > > > affect other architectures. > > > > I am quite confused. Why THP changes are required for hugetlb code for > > ARM? > > Sorry, I was being too vague. We add ARM support for THP in the same patch > series as hugetlb, so I was loosely referring to that lot. OK, it makes more sense now. Thanks for the clarification. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 0/3] Minor changes to common hugetlb code for ARM 2012-09-12 15:27 ` [PATCH 0/3] Minor changes to common hugetlb code for ARM Michal Hocko 2012-09-12 15:55 ` Will Deacon @ 2012-09-13 0:12 ` Andrea Arcangeli 1 sibling, 0 replies; 27+ messages in thread From: Andrea Arcangeli @ 2012-09-13 0:12 UTC (permalink / raw) To: Michal Hocko; +Cc: Will Deacon, linux-mm, linux-kernel, linux-arch, akpm Hi everyone, On Wed, Sep 12, 2012 at 05:27:59PM +0200, Michal Hocko wrote: > On Tue 11-09-12 17:47:13, Will Deacon wrote: > > Hello, > > Hi, > > > A few changes are required to common hugetlb code before the ARM support > > can be merged. I posted the main one previously, which has been picked up > > by akpm: > > > > http://marc.info/?l=linux-mm&m=134573987631394&w=2 > > > > The remaining three patches (included here) are all fairly minor but do > > affect other architectures. > > I am quite confused. Why THP changes are required for hugetlb code for > ARM? Some functions are just noops on x86 and with no arch other than x86 building the huge_memory.c file, those x86-noop parts that needed minor interface adjustments couldn't be noticed until now. Hopefully we got the brainer part right (i.e. the location of the x86 noop callouts), it's clearly untested. > Besides that I would suggest adding Andrea to the CC (added now the > whole series can be found here http://lkml.org/lkml/2012/9/11/322) list > for all THP changes. > > > > > All comments welcome, > > > > Will > > > > Catalin Marinas (2): > > mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() > > mm: thp: Fix the update_mmu_cache() last argument passing in > > mm/huge_memory.c Both: Reviewed-by: Andrea Arcangeli <aarcange@redhat.com> > > > > Steve Capper (1): > > mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE This was already introduced by the s390 THP support which I reviewed a few days ago, and it's already included in -mm, so it can be dropped. Thanks! Andrea ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2012-09-20 19:32 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-09-11 16:47 [PATCH 0/3] Minor changes to common hugetlb code for ARM Will Deacon 2012-09-11 16:47 ` [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() Will Deacon 2012-09-11 17:12 ` Kirill A. Shutemov 2012-09-12 15:30 ` Michal Hocko 2012-09-11 16:47 ` [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c Will Deacon 2012-09-11 17:38 ` Kirill A. Shutemov 2012-09-12 15:40 ` Michal Hocko 2012-09-12 15:51 ` Catalin Marinas 2012-09-15 13:38 ` Ralf Baechle 2012-09-18 19:33 ` Andrew Morton 2012-09-19 9:12 ` Catalin Marinas 2012-09-19 15:53 ` Ralf Baechle 2012-09-20 12:44 ` Will Deacon 2012-09-20 19:32 ` David Miller 2012-09-11 16:47 ` [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE Will Deacon 2012-09-11 17:41 ` Kirill A. Shutemov 2012-09-12 15:32 ` Michal Hocko 2012-09-12 18:06 ` Chris Metcalf 2012-09-12 18:10 ` Will Deacon 2012-09-13 19:05 ` Andrew Morton 2012-09-13 21:26 ` Will Deacon 2012-09-13 21:27 ` Stephen Rothwell 2012-09-13 21:40 ` Andrew Morton 2012-09-12 15:27 ` [PATCH 0/3] Minor changes to common hugetlb code for ARM Michal Hocko 2012-09-12 15:55 ` Will Deacon 2012-09-13 12:22 ` Michal Hocko 2012-09-13 0:12 ` Andrea Arcangeli
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).