Re: [PATCH mm-new v8 4/4] mm: khugepaged: skip lazy-free folios
From: David Hildenbrand (Arm)
Date: Mon Feb 23 2026 - 08:19:29 EST
On 2/21/26 14:38, Vernon Yang wrote:
On Sat, Feb 21, 2026 at 06:27:36PM +0800, Barry Song wrote:
On Sat, Feb 21, 2026 at 5:40 PM Vernon Yang <vernon2gm@xxxxxxxxx> wrote:
From: Vernon Yang <yanglincheng@xxxxxxxxxx>
For example, create three task: hot1 -> cold -> hot2. After all three
task are created, each allocate memory 128MB. the hot1/hot2 task
continuously access 128 MB memory, while the cold task only accesses
its memory briefly and then call madvise(MADV_FREE). However, khugepaged
still prioritizes scanning the cold task and only scans the hot2 task
after completing the scan of the cold task.
And if all folios in VM_DROPPABLE are lazyfree, Collapsing maintains
that property, so we can just collapse and memory pressure in the future
I don’t think this is accurate. A VMA without VM_DROPPABLE
can still have all folios marked as lazyfree. Therefore, having
all folios lazyfree is not the reason why collapsing preserves
the property.
In folio_add_new_anon_rmap(), we know that the vma has the VM_DROPPABLE
attribute, which is the root reason why Collapsing maintains that property.
The above commit log clearly states "all folios in VM_DROPPABLE are lazyfree"
^^^^^^^^^^^^^^^
(the "if" is redundant and should be removed), not "all folios are lazyfree".
Exactly. folio_add_new_anon_rmap() makes sure that all folios (except the shared zero folios ;) ) in VM_DROPPABLE are lazyfree.
In fact, MADV_FREE should be a NOP on VM_DROPPABLE, as folio_mark_lazyfree() doesn't do anything.
This raises a question: if a VMA without VM_DROPPABLE has
many contiguous lazyfree folios that can be collapsed, and
none of those folios are non-lazyfree, should we collapse
them and pass the lazyfree state to the new folio?
I'd assume we'd only want to add support for that when there are actual known use cases that can trigger that + benefit from it.
Adds complexity.
--
Cheers,
David