From: Yang Shi <yang@os.amperecomputing.com>
To: Ryan Roberts <ryan.roberts@arm.com>,
catalin.marinas@arm.com, will@kernel.org, david@redhat.com,
ardb@kernel.org, dev.jain@arm.com, scott@os.amperecomputing.com,
cl@gentwo.org
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] arm64: mm: Optimize range_split_to_ptes()
Date: Thu, 6 Nov 2025 12:47:27 -0800 [thread overview]
Message-ID: <abc692b2-9c1c-47f6-a8f7-5a1f26a98b83@os.amperecomputing.com> (raw)
In-Reply-To: <20251106160945.3182799-3-ryan.roberts@arm.com>
On 11/6/25 8:09 AM, Ryan Roberts wrote:
> Enter lazy_mmu mode while splitting a range of memory to pte mappings.
> This causes barriers, which would otherwise be emitted after every pte
> (and pmd/pud) write, to be deferred until exiting lazy_mmu mode.
>
> For large systems, this is expected to significantly speed up fallback
> to pte-mapping the linear map for the case where the boot CPU has
> BBML2_NOABORT, but secondary CPUs do not. I haven't directly measured
> it, but this is equivalent to commit 1fcb7cea8a5f ("arm64: mm: Batch dsb
> and isb when populating pgtables").
>
> Note that for the path from arch_kfence_init_pool(), we may sleep while
> allocating memory inside the lazy_mmu mode. Sleeping is not allowed by
> generic code inside lazy_mmu, but we know that the arm64 implementation
> is sleep-safe. So this is ok and follows the same pattern already used
> by split_kernel_leaf_mapping().
>
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Reviewed-by: Yang Shi <yang@os.amperecomputing.com>
Thanks,
Yang
> ---
> arch/arm64/mm/mmu.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index a364ac2c9c61..652bb8c14035 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -832,8 +832,14 @@ static const struct mm_walk_ops split_to_ptes_ops = {
>
> static int range_split_to_ptes(unsigned long start, unsigned long end, gfp_t gfp)
> {
> - return walk_kernel_page_table_range_lockless(start, end,
> + int ret;
> +
> + arch_enter_lazy_mmu_mode();
> + ret = walk_kernel_page_table_range_lockless(start, end,
> &split_to_ptes_ops, NULL, &gfp);
> + arch_leave_lazy_mmu_mode();
> +
> + return ret;
> }
>
> static bool linear_map_requires_bbml2 __initdata;
next prev parent reply other threads:[~2025-11-06 20:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-06 16:09 [PATCH v2 0/3] Don't sleep in split_kernel_leaf_mapping() when in atomic context Ryan Roberts
2025-11-06 16:09 ` [PATCH v2 1/3] arm64: mm: " Ryan Roberts
2025-11-06 20:46 ` Yang Shi
2025-11-07 12:10 ` Ryan Roberts
2025-11-06 21:08 ` David Hildenbrand (Red Hat)
2025-11-06 16:09 ` [PATCH v2 2/3] arm64: mm: Optimize range_split_to_ptes() Ryan Roberts
2025-11-06 20:47 ` Yang Shi [this message]
2025-11-06 16:09 ` [PATCH v2 3/3] arm64: mm: Tidy up force_pte_mapping() Ryan Roberts
2025-11-06 20:51 ` Yang Shi
2025-11-06 21:08 ` David Hildenbrand (Red Hat)
2025-11-07 15:53 ` [PATCH v2 0/3] Don't sleep in split_kernel_leaf_mapping() when in atomic context Will Deacon
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=abc692b2-9c1c-47f6-a8f7-5a1f26a98b83@os.amperecomputing.com \
--to=yang@os.amperecomputing.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ryan.roberts@arm.com \
--cc=scott@os.amperecomputing.com \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.