* [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
@ 2020-06-16 22:19 Barry Song
2020-06-17 4:12 ` Anshuman Khandual
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Barry Song @ 2020-06-16 22:19 UTC (permalink / raw)
To: catalin.marinas, will, nsaenzjulienne, steve.capper, rppt, akpm
Cc: linux-arm-kernel, linux-kernel, linuxarm, Barry Song,
Matthias Brugger, Roman Gushchin
hugetlb_cma_reserve() is called at the wrong place. numa_init has not been
done yet. so all reserved memory will be located at node0.
Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Acked-by: Roman Gushchin <guro@fb.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
-v2: add Fixes tag according to Matthias Brugger's comment
arch/arm64/mm/init.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e631e6425165..41914b483d54 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
dma_contiguous_reserve(arm64_dma32_phys_limit);
-
-#ifdef CONFIG_ARM64_4K_PAGES
- hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
-#endif
-
}
void __init bootmem_init(void)
@@ -424,6 +419,11 @@ void __init bootmem_init(void)
min_low_pfn = min;
arm64_numa_init();
+
+#ifdef CONFIG_ARM64_4K_PAGES
+ hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
+#endif
+
/*
* Sparsemem tries to allocate bootmem in memory_present(), so must be
* done after the fixed reservations.
--
2.23.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
2020-06-16 22:19 [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init Barry Song
@ 2020-06-17 4:12 ` Anshuman Khandual
2020-06-17 9:38 ` Matthias Brugger
2020-06-17 10:18 ` Will Deacon
2 siblings, 0 replies; 10+ messages in thread
From: Anshuman Khandual @ 2020-06-17 4:12 UTC (permalink / raw)
To: Barry Song, catalin.marinas, will, nsaenzjulienne, steve.capper,
rppt, akpm
Cc: linux-kernel, linuxarm, Matthias Brugger, Roman Gushchin,
linux-arm-kernel
On 06/17/2020 03:49 AM, Barry Song wrote:
> hugetlb_cma_reserve() is called at the wrong place. numa_init has not been
> done yet. so all reserved memory will be located at node0.
>
> Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Acked-by: Roman Gushchin <guro@fb.com>
> Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> ---
> -v2: add Fixes tag according to Matthias Brugger's comment
>
> arch/arm64/mm/init.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e631e6425165..41914b483d54 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
> high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
>
> dma_contiguous_reserve(arm64_dma32_phys_limit);
> -
> -#ifdef CONFIG_ARM64_4K_PAGES
> - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> -#endif
> -
> }
>
> void __init bootmem_init(void)
> @@ -424,6 +419,11 @@ void __init bootmem_init(void)
> min_low_pfn = min;
>
> arm64_numa_init();
> +
> +#ifdef CONFIG_ARM64_4K_PAGES
> + hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> +#endif
arm64_numa_init() calls numa_init() which initializes node_online_map
that gets used in hugetlb_cma_reserve() while allocating required CMA
size across online nodes.
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
2020-06-16 22:19 [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init Barry Song
2020-06-17 4:12 ` Anshuman Khandual
@ 2020-06-17 9:38 ` Matthias Brugger
2020-06-17 10:18 ` Will Deacon
2 siblings, 0 replies; 10+ messages in thread
From: Matthias Brugger @ 2020-06-17 9:38 UTC (permalink / raw)
To: Barry Song, catalin.marinas, will, nsaenzjulienne, steve.capper,
rppt, akpm
Cc: linux-arm-kernel, linux-kernel, linuxarm, Roman Gushchin
On 17/06/2020 00:19, Barry Song wrote:
> hugetlb_cma_reserve() is called at the wrong place. numa_init has not been
> done yet. so all reserved memory will be located at node0.
>
> Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Acked-by: Roman Gushchin <guro@fb.com>
> Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> -v2: add Fixes tag according to Matthias Brugger's comment
>
> arch/arm64/mm/init.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e631e6425165..41914b483d54 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
> high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
>
> dma_contiguous_reserve(arm64_dma32_phys_limit);
> -
> -#ifdef CONFIG_ARM64_4K_PAGES
> - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> -#endif
> -
> }
>
> void __init bootmem_init(void)
> @@ -424,6 +419,11 @@ void __init bootmem_init(void)
> min_low_pfn = min;
>
> arm64_numa_init();
> +
> +#ifdef CONFIG_ARM64_4K_PAGES
> + hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> +#endif
> +
> /*
> * Sparsemem tries to allocate bootmem in memory_present(), so must be
> * done after the fixed reservations.
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
2020-06-16 22:19 [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init Barry Song
2020-06-17 4:12 ` Anshuman Khandual
2020-06-17 9:38 ` Matthias Brugger
@ 2020-06-17 10:18 ` Will Deacon
2020-06-17 11:38 ` Song Bao Hua (Barry Song)
2 siblings, 1 reply; 10+ messages in thread
From: Will Deacon @ 2020-06-17 10:18 UTC (permalink / raw)
To: Barry Song
Cc: catalin.marinas, nsaenzjulienne, steve.capper, rppt, akpm,
linux-arm-kernel, linux-kernel, linuxarm, Matthias Brugger,
Roman Gushchin
On Wed, Jun 17, 2020 at 10:19:24AM +1200, Barry Song wrote:
> hugetlb_cma_reserve() is called at the wrong place. numa_init has not been
> done yet. so all reserved memory will be located at node0.
>
> Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
Damn, wasn't CC'd on that :/
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> Acked-by: Roman Gushchin <guro@fb.com>
> Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> ---
> -v2: add Fixes tag according to Matthias Brugger's comment
>
> arch/arm64/mm/init.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e631e6425165..41914b483d54 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
> high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
>
> dma_contiguous_reserve(arm64_dma32_phys_limit);
> -
> -#ifdef CONFIG_ARM64_4K_PAGES
> - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> -#endif
Why is this dependent on CONFIG_ARM64_4K_PAGES? We unconditionally
select ARCH_HAS_GIGANTIC_PAGE so this seems unnecessary.
> -
> }
>
> void __init bootmem_init(void)
> @@ -424,6 +419,11 @@ void __init bootmem_init(void)
> min_low_pfn = min;
>
> arm64_numa_init();
> +
> +#ifdef CONFIG_ARM64_4K_PAGES
> + hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> +#endif
A comment here wouldn't hurt, as it does look a lot more natural next
to dma_contiguous_reserve().
Will
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
2020-06-17 10:18 ` Will Deacon
@ 2020-06-17 11:38 ` Song Bao Hua (Barry Song)
2020-06-17 18:20 ` Roman Gushchin
0 siblings, 1 reply; 10+ messages in thread
From: Song Bao Hua (Barry Song) @ 2020-06-17 11:38 UTC (permalink / raw)
To: Will Deacon, Roman Gushchin
Cc: catalin.marinas, nsaenzjulienne, steve.capper, rppt, akpm,
linux-arm-kernel, linux-kernel, Linuxarm, Matthias Brugger
> -----Original Message-----
> From: Will Deacon [mailto:will@kernel.org]
> Sent: Wednesday, June 17, 2020 10:18 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> Cc: catalin.marinas@arm.com; nsaenzjulienne@suse.de;
> steve.capper@arm.com; rppt@linux.ibm.com; akpm@linux-foundation.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; Matthias Brugger <matthias.bgg@gmail.com>;
> Roman Gushchin <guro@fb.com>
> Subject: Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
>
> On Wed, Jun 17, 2020 at 10:19:24AM +1200, Barry Song wrote:
> > hugetlb_cma_reserve() is called at the wrong place. numa_init has not been
> > done yet. so all reserved memory will be located at node0.
> >
> > Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages
> using cma")
>
> Damn, wasn't CC'd on that :/
>
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Acked-by: Roman Gushchin <guro@fb.com>
> > Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> > ---
> > -v2: add Fixes tag according to Matthias Brugger's comment
> >
> > arch/arm64/mm/init.c | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index e631e6425165..41914b483d54 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
> > high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> >
> > dma_contiguous_reserve(arm64_dma32_phys_limit);
> > -
> > -#ifdef CONFIG_ARM64_4K_PAGES
> > - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > -#endif
>
> Why is this dependent on CONFIG_ARM64_4K_PAGES? We unconditionally
> select ARCH_HAS_GIGANTIC_PAGE so this seems unnecessary.
Roman, would you like to answer this question? Have you found any problem if system
doesn't set 4K_PAGES?
>
> > -
> > }
> >
> > void __init bootmem_init(void)
> > @@ -424,6 +419,11 @@ void __init bootmem_init(void)
> > min_low_pfn = min;
> >
> > arm64_numa_init();
> > +
> > +#ifdef CONFIG_ARM64_4K_PAGES
> > + hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > +#endif
>
> A comment here wouldn't hurt, as it does look a lot more natural next
> to dma_contiguous_reserve().
Will add some comment here.
>
> Will
barry
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
2020-06-17 11:38 ` Song Bao Hua (Barry Song)
@ 2020-06-17 18:20 ` Roman Gushchin
2020-06-17 21:43 ` Song Bao Hua (Barry Song)
0 siblings, 1 reply; 10+ messages in thread
From: Roman Gushchin @ 2020-06-17 18:20 UTC (permalink / raw)
To: Song Bao Hua (Barry Song)
Cc: Will Deacon, catalin.marinas, nsaenzjulienne, steve.capper, rppt,
akpm, linux-arm-kernel, linux-kernel, Linuxarm, Matthias Brugger
On Wed, Jun 17, 2020 at 11:38:03AM +0000, Song Bao Hua (Barry Song) wrote:
>
>
> > -----Original Message-----
> > From: Will Deacon [mailto:will@kernel.org]
> > Sent: Wednesday, June 17, 2020 10:18 PM
> > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> > Cc: catalin.marinas@arm.com; nsaenzjulienne@suse.de;
> > steve.capper@arm.com; rppt@linux.ibm.com; akpm@linux-foundation.org;
> > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Linuxarm
> > <linuxarm@huawei.com>; Matthias Brugger <matthias.bgg@gmail.com>;
> > Roman Gushchin <guro@fb.com>
> > Subject: Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
> >
> > On Wed, Jun 17, 2020 at 10:19:24AM +1200, Barry Song wrote:
> > > hugetlb_cma_reserve() is called at the wrong place. numa_init has not been
> > > done yet. so all reserved memory will be located at node0.
> > >
> > > Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages
> > using cma")
> >
> > Damn, wasn't CC'd on that :/
> >
> > > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > > Acked-by: Roman Gushchin <guro@fb.com>
> > > Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> > > ---
> > > -v2: add Fixes tag according to Matthias Brugger's comment
> > >
> > > arch/arm64/mm/init.c | 10 +++++-----
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > index e631e6425165..41914b483d54 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
> > > high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> > >
> > > dma_contiguous_reserve(arm64_dma32_phys_limit);
> > > -
> > > -#ifdef CONFIG_ARM64_4K_PAGES
> > > - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > > -#endif
> >
> > Why is this dependent on CONFIG_ARM64_4K_PAGES? We unconditionally
> > select ARCH_HAS_GIGANTIC_PAGE so this seems unnecessary.
>
> Roman, would you like to answer this question? Have you found any problem if system
> doesn't set 4K_PAGES?
No, I was just following the code in arch/arm64/mm/hugetlbpage.c where all
related to PUD-sized pages is guarded by CONFIG_ARM64_4K_PAGES.
Actually I did all my testing on x86-64, I don't even have any arm hardware.
I'm totally fine with removing this #ifdef if it's not needed.
Thanks!
>
> >
> > > -
> > > }
> > >
> > > void __init bootmem_init(void)
> > > @@ -424,6 +419,11 @@ void __init bootmem_init(void)
> > > min_low_pfn = min;
> > >
> > > arm64_numa_init();
> > > +
> > > +#ifdef CONFIG_ARM64_4K_PAGES
> > > + hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > > +#endif
> >
> > A comment here wouldn't hurt, as it does look a lot more natural next
> > to dma_contiguous_reserve().
>
> Will add some comment here.
>
> >
> > Will
>
> barry
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
2020-06-17 18:20 ` Roman Gushchin
@ 2020-06-17 21:43 ` Song Bao Hua (Barry Song)
2020-06-18 7:19 ` Will Deacon
0 siblings, 1 reply; 10+ messages in thread
From: Song Bao Hua (Barry Song) @ 2020-06-17 21:43 UTC (permalink / raw)
To: Roman Gushchin, Will Deacon
Cc: catalin.marinas, nsaenzjulienne, steve.capper, rppt, akpm,
linux-arm-kernel, linux-kernel, Linuxarm, Matthias Brugger
> -----Original Message-----
> From: Roman Gushchin [mailto:guro@fb.com]
> Sent: Thursday, June 18, 2020 6:20 AM
> To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> Cc: Will Deacon <will@kernel.org>; catalin.marinas@arm.com;
> nsaenzjulienne@suse.de; steve.capper@arm.com; rppt@linux.ibm.com;
> akpm@linux-foundation.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Linuxarm <linuxarm@huawei.com>; Matthias
> Brugger <matthias.bgg@gmail.com>
> Subject: Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
>
> On Wed, Jun 17, 2020 at 11:38:03AM +0000, Song Bao Hua (Barry Song)
> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Will Deacon [mailto:will@kernel.org]
> > > Sent: Wednesday, June 17, 2020 10:18 PM
> > > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> > > Cc: catalin.marinas@arm.com; nsaenzjulienne@suse.de;
> > > steve.capper@arm.com; rppt@linux.ibm.com;
> akpm@linux-foundation.org;
> > > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> Linuxarm
> > > <linuxarm@huawei.com>; Matthias Brugger <matthias.bgg@gmail.com>;
> > > Roman Gushchin <guro@fb.com>
> > > Subject: Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
> > >
> > > On Wed, Jun 17, 2020 at 10:19:24AM +1200, Barry Song wrote:
> > > > hugetlb_cma_reserve() is called at the wrong place. numa_init has not
> been
> > > > done yet. so all reserved memory will be located at node0.
> > > >
> > > > Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic
> hugepages
> > > using cma")
> > >
> > > Damn, wasn't CC'd on that :/
> > >
> > > > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > > > Acked-by: Roman Gushchin <guro@fb.com>
> > > > Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> > > > ---
> > > > -v2: add Fixes tag according to Matthias Brugger's comment
> > > >
> > > > arch/arm64/mm/init.c | 10 +++++-----
> > > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > > index e631e6425165..41914b483d54 100644
> > > > --- a/arch/arm64/mm/init.c
> > > > +++ b/arch/arm64/mm/init.c
> > > > @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
> > > > high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> > > >
> > > > dma_contiguous_reserve(arm64_dma32_phys_limit);
> > > > -
> > > > -#ifdef CONFIG_ARM64_4K_PAGES
> > > > - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > > > -#endif
> > >
> > > Why is this dependent on CONFIG_ARM64_4K_PAGES? We unconditionally
> > > select ARCH_HAS_GIGANTIC_PAGE so this seems unnecessary.
> >
> > Roman, would you like to answer this question? Have you found any
> problem if system
> > doesn't set 4K_PAGES?
>
> No, I was just following the code in arch/arm64/mm/hugetlbpage.c where all
> related to PUD-sized pages is guarded by CONFIG_ARM64_4K_PAGES.
> Actually I did all my testing on x86-64, I don't even have any arm hardware.
>
> I'm totally fine with removing this #ifdef if it's not needed.
At this moment, I would suggest we should keep this "ifdef". Otherwise, hugetlb_cma_reserve() won't be really useful.
For example, while setting PAGE size to 64KB. I got this error in hugetlb_cma_reserve():
hugetlb_cma: cma area should be at least 4194304 MiB
This is absolutely unreasonable.
Supporting hugetlb_cma_reserve() for page sizes other than 4k is a different issue.
It might be addressed in a separate patch later.
>
> Thanks!
>
> >
> > >
> > > > -
> > > > }
> > > >
> > > > void __init bootmem_init(void)
> > > > @@ -424,6 +419,11 @@ void __init bootmem_init(void)
> > > > min_low_pfn = min;
> > > >
> > > > arm64_numa_init();
> > > > +
> > > > +#ifdef CONFIG_ARM64_4K_PAGES
> > > > + hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > > > +#endif
> > >
> > > A comment here wouldn't hurt, as it does look a lot more natural next
> > > to dma_contiguous_reserve().
> >
> > Will add some comment here.
> >
> > >
> > > Will
> >
> > barry
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
2020-06-17 21:43 ` Song Bao Hua (Barry Song)
@ 2020-06-18 7:19 ` Will Deacon
2020-06-18 7:43 ` Song Bao Hua (Barry Song)
0 siblings, 1 reply; 10+ messages in thread
From: Will Deacon @ 2020-06-18 7:19 UTC (permalink / raw)
To: Song Bao Hua (Barry Song)
Cc: Roman Gushchin, catalin.marinas, nsaenzjulienne, steve.capper,
rppt, akpm, linux-arm-kernel, linux-kernel, Linuxarm,
Matthias Brugger
On Wed, Jun 17, 2020 at 09:43:51PM +0000, Song Bao Hua (Barry Song) wrote:
> > From: Roman Gushchin [mailto:guro@fb.com]
> > On Wed, Jun 17, 2020 at 11:38:03AM +0000, Song Bao Hua (Barry Song)
> > > > From: Will Deacon [mailto:will@kernel.org]
> > > > On Wed, Jun 17, 2020 at 10:19:24AM +1200, Barry Song wrote:
> > > > > hugetlb_cma_reserve() is called at the wrong place. numa_init has not
> > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > > > index e631e6425165..41914b483d54 100644
> > > > > --- a/arch/arm64/mm/init.c
> > > > > +++ b/arch/arm64/mm/init.c
> > > > > @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
> > > > > high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> > > > >
> > > > > dma_contiguous_reserve(arm64_dma32_phys_limit);
> > > > > -
> > > > > -#ifdef CONFIG_ARM64_4K_PAGES
> > > > > - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > > > > -#endif
> > > >
> > > > Why is this dependent on CONFIG_ARM64_4K_PAGES? We unconditionally
> > > > select ARCH_HAS_GIGANTIC_PAGE so this seems unnecessary.
> > >
> > > Roman, would you like to answer this question? Have you found any
> > problem if system
> > > doesn't set 4K_PAGES?
> >
> > No, I was just following the code in arch/arm64/mm/hugetlbpage.c where all
> > related to PUD-sized pages is guarded by CONFIG_ARM64_4K_PAGES.
> > Actually I did all my testing on x86-64, I don't even have any arm hardware.
> >
> > I'm totally fine with removing this #ifdef if it's not needed.
>
> At this moment, I would suggest we should keep this "ifdef". Otherwise, hugetlb_cma_reserve() won't be really useful.
>
> For example, while setting PAGE size to 64KB. I got this error in hugetlb_cma_reserve():
> hugetlb_cma: cma area should be at least 4194304 MiB
> This is absolutely unreasonable.
Maybe one for RaspberryPi 5, huh? ;)
But ok, I'll take your patch as-is and add a comment about NUMA.
Thanks,
Will
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
2020-06-18 7:19 ` Will Deacon
@ 2020-06-18 7:43 ` Song Bao Hua (Barry Song)
2020-06-18 7:44 ` Will Deacon
0 siblings, 1 reply; 10+ messages in thread
From: Song Bao Hua (Barry Song) @ 2020-06-18 7:43 UTC (permalink / raw)
To: Will Deacon
Cc: Roman Gushchin, catalin.marinas, nsaenzjulienne, steve.capper,
rppt, akpm, linux-arm-kernel, linux-kernel, Linuxarm,
Matthias Brugger
> -----Original Message-----
> From: Will Deacon [mailto:will@kernel.org]
> Sent: Thursday, June 18, 2020 7:20 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> Cc: Roman Gushchin <guro@fb.com>; catalin.marinas@arm.com;
> nsaenzjulienne@suse.de; steve.capper@arm.com; rppt@linux.ibm.com;
> akpm@linux-foundation.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Linuxarm <linuxarm@huawei.com>; Matthias
> Brugger <matthias.bgg@gmail.com>
> Subject: Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
>
> On Wed, Jun 17, 2020 at 09:43:51PM +0000, Song Bao Hua (Barry Song)
> wrote:
> > > From: Roman Gushchin [mailto:guro@fb.com]
> > > On Wed, Jun 17, 2020 at 11:38:03AM +0000, Song Bao Hua (Barry Song)
> > > > > From: Will Deacon [mailto:will@kernel.org]
> > > > > On Wed, Jun 17, 2020 at 10:19:24AM +1200, Barry Song wrote:
> > > > > > hugetlb_cma_reserve() is called at the wrong place. numa_init has not
> > > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > > > > index e631e6425165..41914b483d54 100644
> > > > > > --- a/arch/arm64/mm/init.c
> > > > > > +++ b/arch/arm64/mm/init.c
> > > > > > @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
> > > > > > high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> > > > > >
> > > > > > dma_contiguous_reserve(arm64_dma32_phys_limit);
> > > > > > -
> > > > > > -#ifdef CONFIG_ARM64_4K_PAGES
> > > > > > - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > > > > > -#endif
> > > > >
> > > > > Why is this dependent on CONFIG_ARM64_4K_PAGES? We
> unconditionally
> > > > > select ARCH_HAS_GIGANTIC_PAGE so this seems unnecessary.
> > > >
> > > > Roman, would you like to answer this question? Have you found any
> > > problem if system
> > > > doesn't set 4K_PAGES?
> > >
> > > No, I was just following the code in arch/arm64/mm/hugetlbpage.c where
> all
> > > related to PUD-sized pages is guarded by CONFIG_ARM64_4K_PAGES.
> > > Actually I did all my testing on x86-64, I don't even have any arm
> hardware.
> > >
> > > I'm totally fine with removing this #ifdef if it's not needed.
> >
> > At this moment, I would suggest we should keep this "ifdef". Otherwise,
> hugetlb_cma_reserve() won't be really useful.
> >
> > For example, while setting PAGE size to 64KB. I got this error in
> hugetlb_cma_reserve():
> > hugetlb_cma: cma area should be at least 4194304 MiB
> > This is absolutely unreasonable.
>
> Maybe one for RaspberryPi 5, huh? ;)
>
> But ok, I'll take your patch as-is and add a comment about NUMA.
Have you seen the v3 with comment? I've already sent.
>
> Thanks,
>
> Will
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
2020-06-18 7:43 ` Song Bao Hua (Barry Song)
@ 2020-06-18 7:44 ` Will Deacon
0 siblings, 0 replies; 10+ messages in thread
From: Will Deacon @ 2020-06-18 7:44 UTC (permalink / raw)
To: Song Bao Hua (Barry Song)
Cc: Roman Gushchin, catalin.marinas, nsaenzjulienne, steve.capper,
rppt, akpm, linux-arm-kernel, linux-kernel, Linuxarm,
Matthias Brugger
On Thu, Jun 18, 2020 at 07:43:43AM +0000, Song Bao Hua (Barry Song) wrote:
>
>
> > -----Original Message-----
> > From: Will Deacon [mailto:will@kernel.org]
> > Sent: Thursday, June 18, 2020 7:20 PM
> > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> > Cc: Roman Gushchin <guro@fb.com>; catalin.marinas@arm.com;
> > nsaenzjulienne@suse.de; steve.capper@arm.com; rppt@linux.ibm.com;
> > akpm@linux-foundation.org; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org; Linuxarm <linuxarm@huawei.com>; Matthias
> > Brugger <matthias.bgg@gmail.com>
> > Subject: Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init
> >
> > On Wed, Jun 17, 2020 at 09:43:51PM +0000, Song Bao Hua (Barry Song)
> > wrote:
> > > > From: Roman Gushchin [mailto:guro@fb.com]
> > > > On Wed, Jun 17, 2020 at 11:38:03AM +0000, Song Bao Hua (Barry Song)
> > > > > > From: Will Deacon [mailto:will@kernel.org]
> > > > > > On Wed, Jun 17, 2020 at 10:19:24AM +1200, Barry Song wrote:
> > > > > > > hugetlb_cma_reserve() is called at the wrong place. numa_init has not
> > > > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > > > > > index e631e6425165..41914b483d54 100644
> > > > > > > --- a/arch/arm64/mm/init.c
> > > > > > > +++ b/arch/arm64/mm/init.c
> > > > > > > @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
> > > > > > > high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> > > > > > >
> > > > > > > dma_contiguous_reserve(arm64_dma32_phys_limit);
> > > > > > > -
> > > > > > > -#ifdef CONFIG_ARM64_4K_PAGES
> > > > > > > - hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > > > > > > -#endif
> > > > > >
> > > > > > Why is this dependent on CONFIG_ARM64_4K_PAGES? We
> > unconditionally
> > > > > > select ARCH_HAS_GIGANTIC_PAGE so this seems unnecessary.
> > > > >
> > > > > Roman, would you like to answer this question? Have you found any
> > > > problem if system
> > > > > doesn't set 4K_PAGES?
> > > >
> > > > No, I was just following the code in arch/arm64/mm/hugetlbpage.c where
> > all
> > > > related to PUD-sized pages is guarded by CONFIG_ARM64_4K_PAGES.
> > > > Actually I did all my testing on x86-64, I don't even have any arm
> > hardware.
> > > >
> > > > I'm totally fine with removing this #ifdef if it's not needed.
> > >
> > > At this moment, I would suggest we should keep this "ifdef". Otherwise,
> > hugetlb_cma_reserve() won't be really useful.
> > >
> > > For example, while setting PAGE size to 64KB. I got this error in
> > hugetlb_cma_reserve():
> > > hugetlb_cma: cma area should be at least 4194304 MiB
> > > This is absolutely unreasonable.
> >
> > Maybe one for RaspberryPi 5, huh? ;)
> >
> > But ok, I'll take your patch as-is and add a comment about NUMA.
>
> Have you seen the v3 with comment? I've already sent.
Thanks, just saw that (I'm going through morning email atm :)
Will
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-06-18 7:44 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-16 22:19 [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init Barry Song
2020-06-17 4:12 ` Anshuman Khandual
2020-06-17 9:38 ` Matthias Brugger
2020-06-17 10:18 ` Will Deacon
2020-06-17 11:38 ` Song Bao Hua (Barry Song)
2020-06-17 18:20 ` Roman Gushchin
2020-06-17 21:43 ` Song Bao Hua (Barry Song)
2020-06-18 7:19 ` Will Deacon
2020-06-18 7:43 ` Song Bao Hua (Barry Song)
2020-06-18 7:44 ` Will Deacon
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).