Thread (58 messages) 58 messages, 7 authors, 2025-09-15

Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections

From: Alexander Gordeev <agordeev@linux.ibm.com>
Date: 2025-09-12 14:06:01
Also in: linux-arm-kernel, linux-mm, lkml, sparclinux, xen-devel

On Fri, Sep 12, 2025 at 03:02:15PM +0200, David Hildenbrand wrote:
How would that work with nesting? I feel like there is a fundamental problem
with nesting with what you describe but I might be wrong.
My picture is - flush on each lazy_mmu_disable(), pause on lazy_mmu_pause()
and honour only top-level arch_enter_lazy_mmu_mode_pte(mm, start, end, ptep) 
context on all nested levels.

In theory (and if I got it right, you leave the door open for this possibility)
every (mm, start, end, ptep) context could be stored for each nesting level
(as an opaque arch-specific data?).

But I do not really expect it ever, since arch_enter_lazy_mmu_mode_pte()
is only to be called in PTE walkers that never span more than one page
table and follow the pattern:

	ptep = pte_offset_map_lock(...);
	arch_enter_lazy_mmu_mode_pte(mm, start, end, ptep);

	for (...; ptep++) {
		/*
		 * set_pte(ptep, ...) or something
		 */
	}

	arch_leave_lazy_mmu_mode();                                             
	pte_unmap_unlock(...);                                         

As result, the lazy mmu mode is only "bound" to a single PTE table on s390,
while arch_enter_lazy_mmu_mode() is going to stay NOP.

So when you say you feel a fundamental problem - what that could be?
David / dhildenb
Thanks!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help