Re: [RFC PATCH 03/57] mm/collapse: add collapse.h for the shared collapse state

From: David Hildenbrand (Arm)

Date: Mon Aug 24 2026 - 07:48:32 EST


On 8/20/26 13:11, Kiryl Shutsemau wrote:
> On Wed, Aug 19, 2026 at 04:19:41PM +0200, David Hildenbrand (Arm) wrote:
>> On 8/17/26 00:45, Kiryl Shutsemau wrote:
>>> From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
>>>
>>> Preparation for building the new collapse engine in its own file. The
>>> engine and khugepaged.c need to agree on what a collapse result is and
>>> what state a scan carries.
>>>
>>> Move enum scan_result and struct collapse_control into a new
>>> mm/collapse.h.
>>>
>>> No functional change intended.
>>>
>>> Assisted-by: Claude-Code:claude-opus-5
>>> Signed-off-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>
>>> ---
>>
>> BTW, I'm wondering whether it would result in less churn (independent of the
>> other changes) to
>>
>> a) Rename mm/khugeapged.c to mm/collapse.c
>>
>> b) Move stuff into mm/collapse.h that a new ...
>>
>> c) mm/khugapegd.c will need.
>
> I went for a clean collapse.c on purpose: the engine is new code, and a
> new file keeps it readable while both mechanisms are in the tree, with 28
> as a plain delete from khugepaged.c.
>
> Your shape is less churn, though, and it keeps blame: 29-35 move about
> 1700 lines as add-and-delete today, and most of that would stay put, with
> only the daemon -- mm_slot, the scan loop, sysfs -- extracted into a new
> khugepaged.c.
>
> If you prefer it that way, I can give it a try for v2.
>
> The rename has to open the series, so it will collide with anything in
> flight that touches khugepaged.c.
>

Kiryl, I have to ask, are you using AI to write your replies?

--
Cheers,

David