linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Sudarshan Rajagopalan <sudaraja@codeaurora.org>,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] arm64: make section size configurable for memory hotplug
Date: Wed, 6 Jan 2021 11:41:26 +0530	[thread overview]
Message-ID: <055b0aca-af60-12ad-cd68-e15440ade64b@arm.com> (raw)
In-Reply-To: <66f79b0c06602c22df4da8ff4a5c2b97c9275250.1609895500.git.sudaraja@codeaurora.org>

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.

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@codeaurora.org>
> ---
>  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@huawei.com/

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

  parent reply	other threads:[~2021-01-06  6:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  1:28 [PATCH 0/1] arm64: make section size configurable for memory hotplug Sudarshan Rajagopalan
2021-01-06  1:28 ` [PATCH 1/1] " Sudarshan Rajagopalan
2021-01-06  2:20   ` Randy Dunlap
2021-01-06  6:11   ` Anshuman Khandual [this message]
2021-01-07 12:30     ` David Hildenbrand
2021-01-08  7:02       ` Anshuman Khandual
2021-01-08 15:30         ` David Hildenbrand
2021-01-11  4:17           ` Anshuman Khandual
2021-01-11 10:13             ` David Hildenbrand
2021-01-11 10:26               ` Anshuman Khandual
2021-01-08  1:01     ` Sudarshan Rajagopalan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=055b0aca-af60-12ad-cd68-e15440ade64b@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sudaraja@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).