From: David Hildenbrand <david@redhat.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
linux-mm@kvack.org, akpm@linux-foundation.org,
mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
npiggin@gmail.com, christophe.leroy@csgroup.eu
Cc: Oscar Salvador <osalvador@suse.de>,
Michal Hocko <mhocko@suse.com>,
Vishal Verma <vishal.l.verma@intel.com>
Subject: Re: [PATCH v3 5/7] powerpc/book3s64/memhotplug: Enable memmap on memory for radix
Date: Tue, 11 Jul 2023 17:26:49 +0200 [thread overview]
Message-ID: <98285185-170f-10fb-67a7-09e35ab47650@redhat.com> (raw)
In-Reply-To: <20230711044834.72809-6-aneesh.kumar@linux.ibm.com>
On 11.07.23 06:48, Aneesh Kumar K.V wrote:
> Radix vmemmap mapping can map things correctly at the PMD level or PTE
> level based on different device boundary checks. Hence we skip the
> restrictions w.r.t vmemmap size to be multiple of PMD_SIZE. This also
> makes the feature widely useful because to use PMD_SIZE vmemmap area we
> require a memory block size of 2GiB
>
> We can also use MHP_RESERVE_PAGES_MEMMAP_ON_MEMORY to that the feature
> can work with a memory block size of 256MB. Using altmap.reserve feature
> to align things correctly at pageblock granularity. We can end up
> losing some pages in memory with this. For ex: with a 256MiB memory block
> size, we require 4 pages to map vmemmap pages, In order to align things
> correctly we end up adding a reserve of 28 pages. ie, for every 4096
> pages 28 pages get reserved.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/pgtable.h | 28 +++++++++++++++++++
> .../platforms/pseries/hotplug-memory.c | 3 +-
> mm/memory_hotplug.c | 2 ++
> 4 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 116d6add0bb0..f890907e5bbf 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -157,6 +157,7 @@ config PPC
> select ARCH_HAS_UBSAN_SANITIZE_ALL
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_KEEP_MEMBLOCK
> + select ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE if PPC_RADIX_MMU
> select ARCH_MIGHT_HAVE_PC_PARPORT
> select ARCH_MIGHT_HAVE_PC_SERIO
> select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
> index 68817ea7f994..8e6c92dde6ad 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -169,6 +169,34 @@ static inline bool is_ioremap_addr(const void *x)
> int __meminit vmemmap_populated(unsigned long vmemmap_addr, int vmemmap_map_size);
> bool altmap_cross_boundary(struct vmem_altmap *altmap, unsigned long start,
> unsigned long page_size);
> +/*
> + * mm/memory_hotplug.c:mhp_supports_memmap_on_memory goes into details
> + * some of the restrictions. We don't check for PMD_SIZE because our
> + * vmemmap allocation code can fallback correctly. The pageblock
> + * alignment requirement is met using altmap->reserve blocks.
> + */
> +#define arch_supports_memmap_on_memory arch_supports_memmap_on_memory
> +static inline bool arch_supports_memmap_on_memory(unsigned long size)
> +{
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + unsigned long vmemmap_size = nr_pages * sizeof(struct page);
> +
> + if (!radix_enabled())
> + return false;
> +
> +#ifdef CONFIG_PPC_4K_PAGES
> + return IS_ALIGNED(vmemmap_size, PMD_SIZE);
> +#else
> + /*
> + * Make sure the vmemmap allocation is fully contianed
> + * so that we always allocate vmemmap memory from altmap area.
> + * The pageblock alignment requirement is met by using
> + * reserve blocks in altmap.
> + */
> + return IS_ALIGNED(vmemmap_size, PAGE_SIZE);
Can we move that check into common code as well?
If our (original) vmemmap size would not fit into a single page, we
would be in trouble on any architecture. Did not check if it would be an
issue for arm64 as well in case we would allow eventually wasting memory.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2023-07-11 15:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 4:48 [PATCH v3 0/7] Add support for memmap on memory feature on ppc64 Aneesh Kumar K.V
2023-07-11 4:48 ` [PATCH v3 1/7] mm/hotplug: Simplify ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE kconfig Aneesh Kumar K.V
2023-07-11 4:48 ` [PATCH v3 2/7] mm/hotplug: Allow memmap on memory hotplug request to fallback Aneesh Kumar K.V
2023-07-11 10:23 ` David Hildenbrand
2023-07-11 15:58 ` Aneesh Kumar K V
2023-07-11 4:48 ` [PATCH v3 3/7] mm/hotplug: Allow architecture to override memmap on memory support check Aneesh Kumar K.V
2023-07-11 10:36 ` David Hildenbrand
2023-07-11 16:07 ` Aneesh Kumar K V
2023-07-11 16:09 ` David Hildenbrand
2023-07-12 20:07 ` John Hubbard
2023-07-13 9:08 ` David Hildenbrand
2023-07-14 23:14 ` John Hubbard
2023-07-11 4:48 ` [PATCH v3 4/7] mm/hotplug: Allow pageblock alignment via altmap reservation Aneesh Kumar K.V
2023-07-11 6:21 ` Huang, Ying
2023-07-11 8:20 ` Aneesh Kumar K V
2023-07-11 17:19 ` David Hildenbrand
2023-07-12 3:16 ` Aneesh Kumar K V
2023-07-12 7:22 ` David Hildenbrand
2023-07-12 13:50 ` Aneesh Kumar K.V
2023-07-12 19:06 ` David Hildenbrand
2023-07-11 4:48 ` [PATCH v3 5/7] powerpc/book3s64/memhotplug: Enable memmap on memory for radix Aneesh Kumar K.V
2023-07-11 15:26 ` David Hildenbrand [this message]
2023-07-11 15:40 ` Aneesh Kumar K V
2023-07-11 15:44 ` David Hildenbrand
2023-07-11 15:46 ` Aneesh Kumar K V
2023-07-11 4:48 ` [PATCH v3 6/7] dax/kmem: Always enroll hotplugged memory for memmap_on_memory Aneesh Kumar K.V
2023-07-11 10:21 ` David Hildenbrand
2023-07-11 4:48 ` [PATCH v3 7/7] mm/hotplug: Embed vmem_altmap details in memory block Aneesh Kumar K.V
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=98285185-170f-10fb-67a7-09e35ab47650@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@suse.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=osalvador@suse.de \
--cc=vishal.l.verma@intel.com \
/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).