diff mbox series

arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZE

Message ID 20211005202529.213812-1-mike.kravetz@oracle.com (mailing list archive)
State New, archived
Headers show
Series arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZE | expand

Commit Message

Mike Kravetz Oct. 5, 2021, 8:25 p.m. UTC
For non-4K PAGE_SIZE configs, the largest gigantic huge page size is
CONT_PMD_SHIFT order.

Fixes: abb7962adc80 ("arm64/hugetlb: Reserve CMA areas for gigantic
pages on 16K and 64K configs")
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: <stable@vger.kernel.org>
---
 arch/arm64/mm/hugetlbpage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Andrew Morton Oct. 5, 2021, 8:54 p.m. UTC | #1
On Tue,  5 Oct 2021 13:25:29 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:

> For non-4K PAGE_SIZE configs, the largest gigantic huge page size is
> CONT_PMD_SHIFT order.

What are the user visible effects of this bug?
Mike Kravetz Oct. 5, 2021, 9:28 p.m. UTC | #2
On 10/5/21 1:54 PM, Andrew Morton wrote:
> On Tue,  5 Oct 2021 13:25:29 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
> 
>> For non-4K PAGE_SIZE configs, the largest gigantic huge page size is
>> CONT_PMD_SHIFT order.
> 
> What are the user visible effects of this bug?
> 
> 

Sorry,
I only recently got easy access to arm64 platforms.  This is what I saw
as a user:

The largest gigantic huge page size on arm64 with 64K PAGE_SIZE 64K is
16G.  Therefore, one should be able to specify 'hugetlb_cma=16G' on the
kernel command line so that 1 gigantic page can be allocated from CMA.
However, when adding such an option the following message is produced:

hugetlb_cma: cma area should be at least 8796093022208 MiB

This is because the calculation for non-4K gigantic page order is
incorrect in the arm64 specific routine arm64_hugetlb_cma_reserve().

Would you like me to send a new version with this in the commit message?
Or, is it easier for you to just add it?
Andrew Morton Oct. 5, 2021, 11:15 p.m. UTC | #3
On Tue, 5 Oct 2021 14:28:03 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:

> On 10/5/21 1:54 PM, Andrew Morton wrote:
> > On Tue,  5 Oct 2021 13:25:29 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
> > 
> >> For non-4K PAGE_SIZE configs, the largest gigantic huge page size is
> >> CONT_PMD_SHIFT order.
> > 
> > What are the user visible effects of this bug?
> > 
> > 
> 
> Sorry,
> I only recently got easy access to arm64 platforms.  This is what I saw
> as a user:
> 
> The largest gigantic huge page size on arm64 with 64K PAGE_SIZE 64K is
> 16G.  Therefore, one should be able to specify 'hugetlb_cma=16G' on the
> kernel command line so that 1 gigantic page can be allocated from CMA.
> However, when adding such an option the following message is produced:
> 
> hugetlb_cma: cma area should be at least 8796093022208 MiB
> 
> This is because the calculation for non-4K gigantic page order is
> incorrect in the arm64 specific routine arm64_hugetlb_cma_reserve().

Cool, thanks.

> Would you like me to send a new version with this in the commit message?
> Or, is it easier for you to just add it?

I assumed that it would be merged via the same path as the offending
abb7962adc80.  Catalin's arm tree, it appears.
Anshuman Khandual Oct. 6, 2021, 7:55 a.m. UTC | #4
On 10/6/21 1:55 AM, Mike Kravetz wrote:
> For non-4K PAGE_SIZE configs, the largest gigantic huge page size is
> CONT_PMD_SHIFT order.
> 
> Fixes: abb7962adc80 ("arm64/hugetlb: Reserve CMA areas for gigantic
> pages on 16K and 64K configs")
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: <stable@vger.kernel.org>

Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>

> ---
>  arch/arm64/mm/hugetlbpage.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 23505fc35324..a8158c948966 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -43,7 +43,7 @@ void __init arm64_hugetlb_cma_reserve(void)
>  #ifdef CONFIG_ARM64_4K_PAGES
>  	order = PUD_SHIFT - PAGE_SHIFT;
>  #else
> -	order = CONT_PMD_SHIFT + PMD_SHIFT - PAGE_SHIFT;
> +	order = CONT_PMD_SHIFT - PAGE_SHIFT;
>  #endif
>  	/*
>  	 * HugeTLB CMA reservation is required for gigantic
> 

The commit a1634a542f74 ("arm64/mm: Redefine CONT_{PTE, PMD}_SHIFT")
which got merged during the exact same week, broke the above commit
as both were in flight. The commit here updated hugetlbpage_init()
but did not update the new incoming arm64_hugetlb_cma_reserve().
Catalin Marinas Oct. 6, 2021, 1:06 p.m. UTC | #5
On Tue, 5 Oct 2021 13:25:29 -0700, Mike Kravetz wrote:
> For non-4K PAGE_SIZE configs, the largest gigantic huge page size is
> CONT_PMD_SHIFT order.

Applied to arm64 (for-next/fixes), thanks!

[1/1] arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZE
      https://git.kernel.org/arm64/c/0350419b14b9
diff mbox series

Patch

diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 23505fc35324..a8158c948966 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -43,7 +43,7 @@  void __init arm64_hugetlb_cma_reserve(void)
 #ifdef CONFIG_ARM64_4K_PAGES
 	order = PUD_SHIFT - PAGE_SHIFT;
 #else
-	order = CONT_PMD_SHIFT + PMD_SHIFT - PAGE_SHIFT;
+	order = CONT_PMD_SHIFT - PAGE_SHIFT;
 #endif
 	/*
 	 * HugeTLB CMA reservation is required for gigantic