From: Ryan Roberts <ryan.roberts@arm•com>
To: Alistair Popple <apopple@nvidia•com>,
linux-arm-kernel@lists•infradead.org
Cc: linux-kernel@vger•kernel.org, linux-mm@kvack•org,
catalin.marinas@arm•com, will@kernel•org, david@kernel•org,
anshuman.khandual@arm•com, dev.jain@arm•com, balbirs@nvidia•com,
jhubbard@nvidia•com
Subject: Re: [PATCH] [RFC] arm64: mmu: use range based TLB flushing when hot unplugging memory
Date: Thu, 21 May 2026 09:50:04 +0100 [thread overview]
Message-ID: <bc96d822-bb68-4945-9f74-68f77e389ac6@arm.com> (raw)
In-Reply-To: <20260521042426.2128731-1-apopple@nvidia.com>
On 21/05/2026 05:24, Alistair Popple wrote:
> Hot unplugging memory on ARM64 requires a TLB invalidate after unmapping
> the page to be hot unplugged from the direct map. Currently that happens
> one page at a time, meaning range based invalidates cannot be used. The
> result of this is that removing large amounts of memory takes a long
> time and in some cases can trigger an RCU stall warning.
>
> For example on one system hot unplugging 480GB of memory takes ~1
> minute. With this change the same operation took ~1 second, a 60x
> improvement.
>
> Signed-off-by: Alistair Popple <apopple@nvidia•com>
>
> ---
>
> This is an RFC, because I'm not sure the change is correct as it frees
> the PTE page before flushing the TLB. I'm not familiar enough with ARM64
> architecture to be sure this is safe, for example I don't know if HW
> can update PTE bits such as access/dirty in the page through a stale
> TLB entry.
>
> If so this would open a window during which the page is free but could
> still be written to. Likely the safe option would be to collect all the
> pages to be free on a list and free them after doing the range based TLB
> flush, but wanted to get feedback on the approach before implementing it
> which is the goal of this RFC.
Hi Alistair,
This patch doesn't apply on v7.1-rc4 because it conflicts with this patch:
Commit 48478b9f79137 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
which has a very similar performance improvement, so hopefully it solves your
problem?
There are two paths which use this logic; unmapping the linear map and unmapping
the corresponding vmemmap. In the latter case, the memory is also freed, so we
can't safely do the range optimizaiton there since the TLB needs to be flushed
before freeing the memory. But the linear map is the big, slow bit so hopefully
it's sufficent for you?
Thanks,
Ryan
> ---
> arch/arm64/mm/mmu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 0c24fe650e95..75c773232c14 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1459,11 +1459,12 @@ static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
>
> WARN_ON(!pte_present(pte));
> __pte_clear(&init_mm, addr, ptep);
> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> if (free_mapped)
> free_hotplug_page_range(pte_page(pte),
> PAGE_SIZE, altmap);
> } while (addr += PAGE_SIZE, addr < end);
> +
> + flush_tlb_kernel_range(addr, end);
> }
>
> static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
next prev parent reply other threads:[~2026-05-21 8:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 4:24 [PATCH] [RFC] arm64: mmu: use range based TLB flushing when hot unplugging memory Alistair Popple
2026-05-21 8:50 ` Ryan Roberts [this message]
2026-05-21 10:46 ` Balbir Singh
2026-05-21 11:24 ` Ryan Roberts
2026-05-21 23:48 ` Alistair Popple
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=bc96d822-bb68-4945-9f74-68f77e389ac6@arm.com \
--to=ryan.roberts@arm$(echo .)com \
--cc=anshuman.khandual@arm$(echo .)com \
--cc=apopple@nvidia$(echo .)com \
--cc=balbirs@nvidia$(echo .)com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=david@kernel$(echo .)org \
--cc=dev.jain@arm$(echo .)com \
--cc=jhubbard@nvidia$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-mm@kvack$(echo .)org \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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