[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3056b153-20a3-ac86-4a49-c26f8be4b2a6@arm.com>
Date: Wed, 26 Jun 2019 13:47:32 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Oscar Salvador <osalvador@...e.de>, akpm@...ux-foundation.org
Cc: mhocko@...e.com, dan.j.williams@...el.com,
pasha.tatashin@...een.com, Jonathan.Cameron@...wei.com,
david@...hat.com, vbabka@...e.cz, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/5] mm,memory_hotplug: allocate memmap from the added
memory range for sparse-vmemmap
Hello Oscar,
On 06/25/2019 01:22 PM, Oscar Salvador wrote:
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 93ed0df4df79..d4b5661fa6b6 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -765,7 +765,10 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> if (pmd_none(READ_ONCE(*pmdp))) {
> void *p = NULL;
>
> - p = vmemmap_alloc_block_buf(PMD_SIZE, node);
> + if (altmap)
> + p = altmap_alloc_block_buf(PMD_SIZE, altmap);
> + else
> + p = vmemmap_alloc_block_buf(PMD_SIZE, node);
> if (!p)
> return -ENOMEM;
Is this really required to be part of this series ? I have an ongoing work
(reworked https://patchwork.kernel.org/patch/10882781/) enabling altmap
support on arm64 during memory hot add and remove path which is waiting on
arm64 memory-hot remove to be merged first.
- Anshuman
Powered by blists - more mailing lists