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

[Kiryl Shutsemau]

On Mon, Aug 24, 2026 at 01:47:54PM +0200, David Hildenbrand (Arm) wrote:
> 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?

Yes. I use it check my claims and fix my grammar.

Why?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov