Re: [PATCH] sparc64: Add 16GB hugepage support

[Nitin Gupta]

On 5/24/17 8:45 PM, David Miller wrote:
> From: Paul Gortmaker 
> Date: Wed, 24 May 2017 23:34:42 -0400
> 
>> [[PATCH] sparc64: Add 16GB hugepage support] On 24/05/2017 (Wed 17:29) Nitin 
>> Gupta wrote:
>>
>>> Orabug: 25362942
>>>
>>> Signed-off-by: Nitin Gupta 
>>
>> If this wasn't an accidental git send-email misfire, then there should
>> be a long log indicating the use case, the perforamnce increase, the
>> testing that was done, etc. etc. 
>>
>> Normally I'd not notice but since I was Cc'd I figured it was worth a
>> mention -- for example the vendor ID above doesn't mean a thing to
>> all the rest of us, hence why I suspect it was a git send-email misfire;
>> sadly, I think we've all accidentally done that at least once
> 
> Agreed.
> 
> No commit message whatsoever is basically unacceptable for something
> like this.
>

Ok, I will include usage, testing notes, performance numbers etc., in
v2 patch. Still, I do try to include "Orabug" for better tracking of
bugs internally; I hope that's okay.

Thanks,
Nitin

Re: [PATCH] sparc64: Add 16GB hugepage support

[Nitin Gupta]

On 5/24/17 8:45 PM, David Miller wrote:
> From: Paul Gortmaker 
> Date: Wed, 24 May 2017 23:34:42 -0400
> 
>> [[PATCH] sparc64: Add 16GB hugepage support] On 24/05/2017 (Wed 17:29) Nitin 
>> Gupta wrote:
>>
>>> Orabug: 25362942
>>>
>>> Signed-off-by: Nitin Gupta 
>>
>> If this wasn't an accidental git send-email misfire, then there should
>> be a long log indicating the use case, the perforamnce increase, the
>> testing that was done, etc. etc. 
>>
>> Normally I'd not notice but since I was Cc'd I figured it was worth a
>> mention -- for example the vendor ID above doesn't mean a thing to
>> all the rest of us, hence why I suspect it was a git send-email misfire;
>> sadly, I think we've all accidentally done that at least once
> 
> Agreed.
> 
> No commit message whatsoever is basically unacceptable for something
> like this.
>

Ok, I will include usage, testing notes, performance numbers etc., in
v2 patch. Still, I do try to include "Orabug" for better tracking of
bugs internally; I hope that's okay.

Thanks,
Nitin

Re: [PATCH] sparc64: Add 16GB hugepage support

[David Miller]

From: Paul Gortmaker 
Date: Wed, 24 May 2017 23:34:42 -0400

> [[PATCH] sparc64: Add 16GB hugepage support] On 24/05/2017 (Wed 17:29) Nitin 
> Gupta wrote:
> 
>> Orabug: 25362942
>> 
>> Signed-off-by: Nitin Gupta 
> 
> If this wasn't an accidental git send-email misfire, then there should
> be a long log indicating the use case, the perforamnce increase, the
> testing that was done, etc. etc. 
> 
> Normally I'd not notice but since I was Cc'd I figured it was worth a
> mention -- for example the vendor ID above doesn't mean a thing to
> all the rest of us, hence why I suspect it was a git send-email misfire;
> sadly, I think we've all accidentally done that at least once

Agreed.

No commit message whatsoever is basically unacceptable for something
like this.

Re: [PATCH] sparc64: Add 16GB hugepage support

[David Miller]

From: Paul Gortmaker 
Date: Wed, 24 May 2017 23:34:42 -0400

> [[PATCH] sparc64: Add 16GB hugepage support] On 24/05/2017 (Wed 17:29) Nitin 
> Gupta wrote:
> 
>> Orabug: 25362942
>> 
>> Signed-off-by: Nitin Gupta 
> 
> If this wasn't an accidental git send-email misfire, then there should
> be a long log indicating the use case, the perforamnce increase, the
> testing that was done, etc. etc. 
> 
> Normally I'd not notice but since I was Cc'd I figured it was worth a
> mention -- for example the vendor ID above doesn't mean a thing to
> all the rest of us, hence why I suspect it was a git send-email misfire;
> sadly, I think we've all accidentally done that at least once

Agreed.

No commit message whatsoever is basically unacceptable for something
like this.

Re: [PATCH] sparc64: Add 16GB hugepage support

[Paul Gortmaker]

[[PATCH] sparc64: Add 16GB hugepage support] On 24/05/2017 (Wed 17:29) Nitin 
Gupta wrote:

> Orabug: 25362942
> 
> Signed-off-by: Nitin Gupta 

If this wasn't an accidental git send-email misfire, then there should
be a long log indicating the use case, the perforamnce increase, the
testing that was done, etc. etc. 

Normally I'd not notice but since I was Cc'd I figured it was worth a
mention -- for example the vendor ID above doesn't mean a thing to
all the rest of us, hence why I suspect it was a git send-email misfire;
sadly, I think we've all accidentally done that at least once

Paul.
--

> ---
>  arch/sparc/include/asm/page_64.h|  3 +-
>  arch/sparc/include/asm/pgtable_64.h |  5 +++
>  arch/sparc/include/asm/tsb.h| 35 +-
>  arch/sparc/kernel/tsb.S |  2 +-
>  arch/sparc/mm/hugetlbpage.c | 74 
> ++---
>  arch/sparc/mm/init_64.c | 41 
>  6 files changed, 128 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/sparc/include/asm/page_64.h 
> b/arch/sparc/include/asm/page_64.h
> index 5961b2d..8ee1f97 100644
> --- a/arch/sparc/include/asm/page_64.h
> +++ b/arch/sparc/include/asm/page_64.h
> @@ -17,6 +17,7 @@
>  
>  #define HPAGE_SHIFT  23
>  #define REAL_HPAGE_SHIFT 22
> +#define HPAGE_16GB_SHIFT 34
>  #define HPAGE_2GB_SHIFT  31
>  #define HPAGE_256MB_SHIFT28
>  #define HPAGE_64K_SHIFT  16
> @@ -28,7 +29,7 @@
>  #define HUGETLB_PAGE_ORDER   (HPAGE_SHIFT - PAGE_SHIFT)
>  #define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
>  #define REAL_HPAGE_PER_HPAGE (_AC(1,UL) << (HPAGE_SHIFT - REAL_HPAGE_SHIFT))
> -#define HUGE_MAX_HSTATE  4
> +#define HUGE_MAX_HSTATE  5
>  #endif
>  
>  #ifndef __ASSEMBLY__
> diff --git a/arch/sparc/include/asm/pgtable_64.h 
> b/arch/sparc/include/asm/pgtable_64.h
> index 6fbd931..2444b02 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -414,6 +414,11 @@ static inline bool is_hugetlb_pmd(pmd_t pmd)
>   return !!(pmd_val(pmd) & _PAGE_PMD_HUGE);
>  }
>  
> +static inline bool is_hugetlb_pud(pud_t pud)
> +{
> + return !!(pud_val(pud) & _PAGE_PUD_HUGE);
> +}
> +
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  static inline pmd_t pmd_mkhuge(pmd_t pmd)
>  {
> diff --git a/arch/sparc/include/asm/tsb.h b/arch/sparc/include/asm/tsb.h
> index 32258e0..fbd8da7 100644
> --- a/arch/sparc/include/asm/tsb.h
> +++ b/arch/sparc/include/asm/tsb.h
> @@ -195,6 +195,36 @@ extern struct tsb_phys_patch_entry __tsb_phys_patch, 
> __tsb_phys_patch_end;
>nop; \
>  699:
>  
> + /* PUD has been loaded into REG1, interpret the value, seeing
> +  * if it is a HUGE PUD or a normal one.  If it is not valid
> +  * then jump to FAIL_LABEL.  If it is a HUGE PUD, and it
> +  * translates to a valid PTE, branch to PTE_LABEL.
> +  *
> +  * We have to propagate bits [32:22] from the virtual address
> +  * to resolve at 4M granularity.
> +  */
> +#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
> +#define USER_PGTABLE_CHECK_PUD_HUGE(VADDR, REG1, REG2, FAIL_LABEL, 
> PTE_LABEL) \
> + brz,pn  REG1, FAIL_LABEL;   \
> +  sethi  %uhi(_PAGE_PUD_HUGE), REG2; \
> + sllxREG2, 32, REG2; \
> + andcc   REG1, REG2, %g0;\
> + be,pt   %xcc, 700f; \
> +  sethi  %hi(0x1ffc), REG2;  \
> + brgez,pnREG1, FAIL_LABEL;   \
> +  sllx   REG2, 1, REG2;  \
> + brgez,pnREG1, FAIL_LABEL;   \
> +  andn   REG1, REG2, REG1;   \
> + and VADDR, REG2, REG2;  \
> + brlz,pt REG1, PTE_LABEL;\
> +  or REG1, REG2, REG1;   \
> +700:
> +#else
> +#define USER_PGTABLE_CHECK_PUD_HUGE(VADDR, REG1, REG2, FAIL_LABEL, 
> PTE_LABEL) \
> + brz,pn  REG1, FAIL_LABEL; \
> +  nop;
> +#endif
> +
>   /* PMD has been loaded into REG1, interpret the value, seeing
>* if it is a HUGE PMD or a normal one.  If it is not valid
>* then jump to FAIL_LABEL.  If it is a HUGE PMD, and it
> @@ -209,14 +239,14 @@ extern struct tsb_phys_patch_entry __tsb_phys_patch, 
> __tsb_phys_patch_end;
>sethi  %uhi(_PAGE_PMD_HUGE), REG2; \
>   sllxREG2, 32, REG2; \
>   andcc   REG1, REG2, %g0;\
> - be,pt   %xcc, 700f; \
> + be,pt   %xcc, 701f; \
>sethi  %hi(4 * 1024 * 1024), REG2; \
>   brgez,pnREG1, FAIL_LABEL;   \
>andn   REG1, REG2, REG1;   \
>   and VADDR, REG2, REG2;  \
>   

Re: [PATCH] sparc64: Add 16GB hugepage support

[Paul Gortmaker]

[[PATCH] sparc64: Add 16GB hugepage support] On 24/05/2017 (Wed 17:29) Nitin 
Gupta wrote:

> Orabug: 25362942
> 
> Signed-off-by: Nitin Gupta 

If this wasn't an accidental git send-email misfire, then there should
be a long log indicating the use case, the perforamnce increase, the
testing that was done, etc. etc. 

Normally I'd not notice but since I was Cc'd I figured it was worth a
mention -- for example the vendor ID above doesn't mean a thing to
all the rest of us, hence why I suspect it was a git send-email misfire;
sadly, I think we've all accidentally done that at least once

Paul.
--

> ---
>  arch/sparc/include/asm/page_64.h|  3 +-
>  arch/sparc/include/asm/pgtable_64.h |  5 +++
>  arch/sparc/include/asm/tsb.h| 35 +-
>  arch/sparc/kernel/tsb.S |  2 +-
>  arch/sparc/mm/hugetlbpage.c | 74 
> ++---
>  arch/sparc/mm/init_64.c | 41 
>  6 files changed, 128 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/sparc/include/asm/page_64.h 
> b/arch/sparc/include/asm/page_64.h
> index 5961b2d..8ee1f97 100644
> --- a/arch/sparc/include/asm/page_64.h
> +++ b/arch/sparc/include/asm/page_64.h
> @@ -17,6 +17,7 @@
>  
>  #define HPAGE_SHIFT  23
>  #define REAL_HPAGE_SHIFT 22
> +#define HPAGE_16GB_SHIFT 34
>  #define HPAGE_2GB_SHIFT  31
>  #define HPAGE_256MB_SHIFT28
>  #define HPAGE_64K_SHIFT  16
> @@ -28,7 +29,7 @@
>  #define HUGETLB_PAGE_ORDER   (HPAGE_SHIFT - PAGE_SHIFT)
>  #define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
>  #define REAL_HPAGE_PER_HPAGE (_AC(1,UL) << (HPAGE_SHIFT - REAL_HPAGE_SHIFT))
> -#define HUGE_MAX_HSTATE  4
> +#define HUGE_MAX_HSTATE  5
>  #endif
>  
>  #ifndef __ASSEMBLY__
> diff --git a/arch/sparc/include/asm/pgtable_64.h 
> b/arch/sparc/include/asm/pgtable_64.h
> index 6fbd931..2444b02 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -414,6 +414,11 @@ static inline bool is_hugetlb_pmd(pmd_t pmd)
>   return !!(pmd_val(pmd) & _PAGE_PMD_HUGE);
>  }
>  
> +static inline bool is_hugetlb_pud(pud_t pud)
> +{
> + return !!(pud_val(pud) & _PAGE_PUD_HUGE);
> +}
> +
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  static inline pmd_t pmd_mkhuge(pmd_t pmd)
>  {
> diff --git a/arch/sparc/include/asm/tsb.h b/arch/sparc/include/asm/tsb.h
> index 32258e0..fbd8da7 100644
> --- a/arch/sparc/include/asm/tsb.h
> +++ b/arch/sparc/include/asm/tsb.h
> @@ -195,6 +195,36 @@ extern struct tsb_phys_patch_entry __tsb_phys_patch, 
> __tsb_phys_patch_end;
>nop; \
>  699:
>  
> + /* PUD has been loaded into REG1, interpret the value, seeing
> +  * if it is a HUGE PUD or a normal one.  If it is not valid
> +  * then jump to FAIL_LABEL.  If it is a HUGE PUD, and it
> +  * translates to a valid PTE, branch to PTE_LABEL.
> +  *
> +  * We have to propagate bits [32:22] from the virtual address
> +  * to resolve at 4M granularity.
> +  */
> +#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
> +#define USER_PGTABLE_CHECK_PUD_HUGE(VADDR, REG1, REG2, FAIL_LABEL, 
> PTE_LABEL) \
> + brz,pn  REG1, FAIL_LABEL;   \
> +  sethi  %uhi(_PAGE_PUD_HUGE), REG2; \
> + sllxREG2, 32, REG2; \
> + andcc   REG1, REG2, %g0;\
> + be,pt   %xcc, 700f; \
> +  sethi  %hi(0x1ffc), REG2;  \
> + brgez,pnREG1, FAIL_LABEL;   \
> +  sllx   REG2, 1, REG2;  \
> + brgez,pnREG1, FAIL_LABEL;   \
> +  andn   REG1, REG2, REG1;   \
> + and VADDR, REG2, REG2;  \
> + brlz,pt REG1, PTE_LABEL;\
> +  or REG1, REG2, REG1;   \
> +700:
> +#else
> +#define USER_PGTABLE_CHECK_PUD_HUGE(VADDR, REG1, REG2, FAIL_LABEL, 
> PTE_LABEL) \
> + brz,pn  REG1, FAIL_LABEL; \
> +  nop;
> +#endif
> +
>   /* PMD has been loaded into REG1, interpret the value, seeing
>* if it is a HUGE PMD or a normal one.  If it is not valid
>* then jump to FAIL_LABEL.  If it is a HUGE PMD, and it
> @@ -209,14 +239,14 @@ extern struct tsb_phys_patch_entry __tsb_phys_patch, 
> __tsb_phys_patch_end;
>sethi  %uhi(_PAGE_PMD_HUGE), REG2; \
>   sllxREG2, 32, REG2; \
>   andcc   REG1, REG2, %g0;\
> - be,pt   %xcc, 700f; \
> + be,pt   %xcc, 701f; \
>sethi  %hi(4 * 1024 * 1024), REG2; \
>   brgez,pnREG1, FAIL_LABEL;   \
>andn   REG1, REG2, REG1;   \
>   and VADDR, REG2, REG2;  \
>   brlz,pt REG1,