Re: [RFC PATCH 03/57] mm/collapse: add collapse.h for the shared collapse state
From: Kiryl Shutsemau <hidden>
Date: 2026-08-24 12:10:28
Also in:
bpf, linux-kselftest, linux-mm, lkml
On Mon, Aug 24, 2026 at 01:47:54PM +0200, David Hildenbrand (Arm) wrote:
On 8/20/26 13:11, Kiryl Shutsemau wrote:quoted
On Wed, Aug 19, 2026 at 04:19:41PM +0200, David Hildenbrand (Arm) wrote:quoted
On 8/17/26 00:45, Kiryl Shutsemau wrote:quoted
From: "Kiryl Shutsemau (Meta)" <kas@kernel.org> 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@kernel.org> ---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