Re: [PATCH 00/12] mm/collapse: separate a collapse from its callers

[Andrew Morton]

On Fri,  4 Sep 2026 16:10:14 +0100 Kiryl Shutsemau <kirill@xxxxxxxxxxxxx> wrote:

> From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
> 
> [ This is the first of the cleanups I said I would front-load ]
> 
> There is no line between the collapse engine and the callers that ask for
> a collapse.  khugepaged.c holds both, and they reach into each other.
> 
>  - Sixteen tests through the collapse path read cc->is_khugepaged to work
>    out what they are allowed to do, when every one of those decisions was
>    made by the caller before it asked.
> 
>  - collapse_single_pmd() does both halves of a collapse behind one call and
>    drops mmap_lock somewhere in the middle.  Which of its paths dropped it
>    is not something a caller can see, so it hands back a bool and the
>    caller keeps track.
> 
>  - MADV_COLLAPSE's implementation -- the walk over the user's range, the
>    per-PMD loop, the errno translation -- sits in khugepaged.c, which is
>    the daemon's file.
> 
> So: draw the line.  State what a caller allows in a policy, split the call
> in two with the lock as the boundary, and move the syscall to madvise.c.
> What the engine offers is then four calls, with the lock state written
> down against each, and a policy the caller fills for itself:
> 
> ...
> 
> Behaviour
> =========
> 
> Nothing here changes what gets collapsed.  Three things a reader should
> not have to find in the diff:
> 
>  - Patch 5: khugepaged fills its policy once per scan pass, so the
>    max_ptes_* limits and the defrag setting behind the allocation mask are
>    sampled once per pass rather than once per table.  A table scanned early
>    in a pass and one scanned late are then judged alike, where before a
>    knob written mid-pass split them.
> 
>  - Patch 8: mm_khugepaged_scan_pmd fires before mm_collapse_huge_page
>    rather than after it, the scan having returned before the collapse
>    runs.  Its status field already reads SCAN_SUCCEED for an accepted
>    table, so nothing changes there; what the collapse then made of the
>    table is mm_collapse_huge_page's to report, per order.
> 
>  - Patch 10: which orders a table is scanned for is sampled once per VMA
>    rather than once per table.  It cannot widen what a collapse does --
>    the order is tested again under the lock the collapse retakes.

So is *any* functional change expected with this series?

I'm reluctant to merge an unreviewed v1, but this comes close!  I'll
sit on it for a week or less, see what people say.  Please poke me
if/when you think it's good for mm-new.