Thread (45 messages) flat view 45 messages, 3 authors, 6d ago

Re: [PATCH v2 06/26] mm/fbatch: fbatch_drain_lazyfree(onstack fbatch) before ptl unlock

From: Hugh Dickins <hughd@google.com>
Date: 2026-09-12 22:07:24
Also in: linux-fsdevel, linux-mm, lkml

On Wed, 9 Sep 2026, Vlastimil Babka (SUSE) wrote:
On 9/9/26 11:53, Hugh Dickins wrote:
quoted
Re-enable lazyfree batching for MADV_FREE. But it's not safe now to leave
potentially stale (then reused) folios in a per-cpu fbatch for lazyfree.
Instead, madvise_free_pte_range() keep an fbatch on its stack, and drain
it each time before dropping pagetable lock, while the folios are secure.

Ignore folio_may_be_lru_cached() and lru_cache_disabled(): limitations
irrelevant to this fbatch drained under spinlock (even if RT); though
in practice madvise_free_huge_pmd() does have to drain every time.

Signed-off-by: Hugh Dickins <hughd@google.com>
It seems correct to me, so:

Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Thanks.
Might be that something regresses performance though. Guess we'll see.

Also seems to me that if this patch was preparatory, the batching wouldn't
have to be temporarily disabled. Doesn't matter ultimately though.
That's true, the order of patches does rather reflect the order in
which I got to think about things - but I thought it might be easiest
to review in this way too. I was anxious to get to the core patch (04/26)
as quickly as possible, to find out whether the idea would fly at all;
I could see lazyfree was a problem, but wanted to put off its solution.

Hugh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help