[PATCH 0/3] Minor changes to common hugetlb code for ARM

[PATCH 0/3] Minor changes to common hugetlb code for ARM

[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

[PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear()

[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

[PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[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

[PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

[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

Re: [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear()

[Kirill A. Shutemov]

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

Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[Kirill A. Shutemov]

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

Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

[Kirill A. Shutemov]

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

Re: [PATCH 0/3] Minor changes to common hugetlb code for ARM

[Michal Hocko]

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

Re: [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear()

[Michal Hocko]

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

Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

[Michal Hocko]

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

Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[Michal Hocko]

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

Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[Catalin Marinas]

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

Re: [PATCH 0/3] Minor changes to common hugetlb code for ARM

[Will Deacon]

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

Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

[Chris Metcalf]

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

Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

[Will Deacon]

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

Re: [PATCH 0/3] Minor changes to common hugetlb code for ARM

[Andrea Arcangeli]

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

Re: [PATCH 0/3] Minor changes to common hugetlb code for ARM

[Michal Hocko]

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

Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

[Andrew Morton]

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

Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

[Will Deacon]

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

Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

[Stephen Rothwell]

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

Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

[Andrew Morton]

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
_

Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[Ralf Baechle]

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

Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[Andrew Morton]

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?

Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[Catalin Marinas]

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

Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[Ralf Baechle]

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

Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[Will Deacon]

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

Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c

[David Miller]

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.