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

[Hugh Dickins]

On Wed, 9 Sep 2026, Vlastimil Babka (SUSE) wrote:
> On 9/9/26 11:53, Hugh Dickins wrote:
> > 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@xxxxxxxxxx>
> 
> It seems correct to me, so:
> 
> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>

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