Re: [PATCH 1/1] arm64: make section size configurable for memory hotplug

[Sudarshan Rajagopalan]

On 2021-01-05 22:11, Anshuman Khandual wrote:

Hello Anshuman, thanks for your response.


(+ Will)

> Hi Sudershan,
>
> This patch (and the cover letter) does not copy LAKML even though the
> entire change here is arm64 specific. Please do copy all applicable
> mailing lists for a given patch.

I used ./scripts/get_maintainer.pl patch.patch to get the maintainers 
list. It somehow didn't mention LAKML. I've added the mailing list to 
this thread.

> On 1/6/21 6:58 AM, Sudarshan Rajagopalan wrote:
> > Currently on arm64, memory section size is hard-coded to 1GB.
> > Make this configurable if memory-hotplug is enabled, to support
> > more finer granularity for hotplug-able memory.
>
> Section size has always been decided by the platform. It cannot be a
> configurable option because the user would not know the constraints
> for memory representation on the platform and besides it also cannot
> be trusted.
>
> > Signed-off-by: Sudarshan Rajagopalan <sudaraja@xxxxxxxxxxxxxx>
> > ---
> >  arch/arm64/Kconfig                 | 11 +++++++++++
> >  arch/arm64/include/asm/sparsemem.h |  4 ++++
> >  2 files changed, 15 insertions(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 6d232837cbee..34124eee65da 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -294,6 +294,17 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
> >  config SMP
> >  	def_bool y
> >
> > +config HOTPLUG_SIZE_BITS
> > +	int "Memory hotplug block size(29 => 512MB 30 => 1GB)"
> > +	depends on SPARSEMEM
> > +	depends on MEMORY_HOTPLUG
> > +	range 28 30
>
> 28 would not work for 64K pages.
>
> > +	default 30
> > +	help
> > +	 Selects granularity of hotplug memory. Block size for
> > +	 memory hotplug is represent as a power of 2.
> > +	 If unsure, stick with default value.
> > +
> >  config KERNEL_MODE_NEON
> >  	def_bool y
> >
> > diff --git a/arch/arm64/include/asm/sparsemem.h 
> > b/arch/arm64/include/asm/sparsemem.h
> > index 1f43fcc79738..3d5310f3aad5 100644
> > --- a/arch/arm64/include/asm/sparsemem.h
> > +++ b/arch/arm64/include/asm/sparsemem.h
> > @@ -7,7 +7,11 @@
> >
> >  #ifdef CONFIG_SPARSEMEM
> >  #define MAX_PHYSMEM_BITS	CONFIG_ARM64_PA_BITS
> > +#ifndef CONFIG_MEMORY_HOTPLUG
> >  #define SECTION_SIZE_BITS	30
> > +#else
> > +#define SECTION_SIZE_BITS	CONFIG_HOTPLUG_SIZE_BITS
> > +#endif
> >  #endif
> >
> >  #endif
>
> There was an inconclusive discussion regarding this last month.
>
> https://lore.kernel.org/linux-arm-kernel/20201204014443.43329-1-liwei213@xxxxxxxxxx/

Thanks for pointing out this thread. Looking into all the comments, 
major concern with reducing the section size seems to be risk of running 
out of bits in the page flags. And while SECTION_SIZE must be greater or 
equal to highest order page in the buddy, it must also satisfy cases for 
4K page size where it doesn't break PMD mapping for vmemmap - and hence 
SECTION_SIZE_BITS of 27 could be set for 4K page size that could allow 
2MB PMD mappings for each 128M(2^27) block size.

While this is the least value that can be set (27 for 4K_PAGE, 
MAX_ZONEORDER - 1 + PAGE_SHIFT for 16K or 64K_PAGE), are there any 
concerns with setting higher values (but <= 30bits). It seems like any 
arbitrary number between this range could be applied that wouldn't break 
vmemmaps. That's why we were thinking of letting the user configure it 
since this directly impacts memory hotplug about the granularity or 
least size that can be hot (up)plugged. The current setting of 1GB for 
arm64 does poses a lot of challenges in utilizing memory hotplug via a 
driver, esp. for low RAM targets. I agree its sub-optimal in some sense 
but wanted to know the maintainers opinion on this.

Also, the patch introduced in that thread does seem to help reduce 
vmemmap memory if there are large holes. So there is some merit in 
reducing the section size along with memory hotplug leveraging it.

> I have been wondering if this would solve the problem for 4K page size
> config which requires PMD mapping for the vmemmap mapping while making
> section size bits dependent on max order. But this has not been tested
> properly.
>
> diff --git a/arch/arm64/include/asm/sparsemem.h
> b/arch/arm64/include/asm/sparsemem.h
> index 1f43fcc79738..fe4353cb1dce 100644
> --- a/arch/arm64/include/asm/sparsemem.h
> +++ b/arch/arm64/include/asm/sparsemem.h
> @@ -7,7 +7,18 @@
>
>  #ifdef CONFIG_SPARSEMEM
>  #define MAX_PHYSMEM_BITS       CONFIG_ARM64_PA_BITS
> -#define SECTION_SIZE_BITS      30
> -#endif
> +
> +#ifdef CONFIG_ARM64_4K_PAGES
> +#define SECTION_SIZE_BITS 27
> +#else
> +#ifdef CONFIG_FORCE_MAX_ZONEORDER
> +#define SECTION_SIZE_BITS (CONFIG_FORCE_MAX_ZONEORDER - 1 + 
> PAGE_SHIFT)
> +#else
> +#define SECTION_SIZE_BITS 30
> +#endif /* CONFIG_FORCE_MAX_ZONEORDER */
> +
> +#endif /* CONFIG_ARM64_4K_PAGES */
> +
> +#endif /* CONFIG_SPARSEMEM*/
>
>  #endif

SECTION_SIZE_BITS of 27 for 4K_PAGES should be fine for us. Would you 
know if there's possibility of this patch above being applied in 
upstream anytime soon? This is in regards with Generic Kernel Image 
(GKI) that we are working with Google. If this patch would positively 
end up in upstream, we could apply it in aosp kernel.


Sudarshan

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project