Re: [PATCH v3 05/13] mm: introduce CONFIG_ARCH_LAZY_MMU
From: Mike Rapoport <rppt@kernel.org>
Date: 2025-10-18 09:53:10
Also in:
linux-arm-kernel, linux-mm, lkml, sparclinux, xen-devel
On Wed, Oct 15, 2025 at 09:27:19AM +0100, Kevin Brodsky wrote:
Architectures currently opt in for implementing lazy_mmu helpers by defining __HAVE_ARCH_ENTER_LAZY_MMU_MODE. In preparation for introducing a generic lazy_mmu layer that will require storage in task_struct, let's switch to a cleaner approach: instead of defining a macro, select a CONFIG option. This patch introduces CONFIG_ARCH_LAZY_MMU and has each arch select it when it implements lazy_mmu helpers. __HAVE_ARCH_ENTER_LAZY_MMU_MODE is removed and <linux/pgtable.h> relies on the new CONFIG instead. On x86, lazy_mmu helpers are only implemented if PARAVIRT_XXL is selected. This creates some complications in arch/x86/boot/, because a few files manually undefine PARAVIRT* options. As a result <asm/paravirt.h> does not define the lazy_mmu helpers, but this breaks the build as <linux/pgtable.h> only defines them if !CONFIG_ARCH_LAZY_MMU. There does not seem to be a clean way out of this - let's just undefine that new CONFIG too. Signed-off-by: Kevin Brodsky <redacted> ---
...
quoted hunk ↗ jump to hunk
@@ -231,7 +231,7 @@ static inline int pmd_dirty(pmd_t pmd) * held, but for kernel PTE updates, no lock is held). Nesting is not permitted * and the mode cannot be used in interrupt context. */ -#ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE +#ifndef CONFIG_ARCH_LAZY_MMU static inline void arch_enter_lazy_mmu_mode(void) {} static inline void arch_leave_lazy_mmu_mode(void) {} static inline void arch_flush_lazy_mmu_mode(void) {}diff --git a/mm/Kconfig b/mm/Kconfig index 0e26f4fc8717..2fdcb42ca1a1 100644 --- a/mm/Kconfig +++ b/mm/Kconfig@@ -1372,6 +1372,9 @@ config PT_RECLAIM config FIND_NORMAL_PAGE def_bool n +config ARCH_LAZY_MMU + bool +
I think a better name would be ARCH_HAS_LAZY_MMU and the config option fits better to arch/Kconfig.
source "mm/damon/Kconfig" endmenu -- 2.47.0
-- Sincerely yours, Mike.