Thread (119 messages) 119 messages, 9 authors, 15d ago

Re: [RFC PATCH 00/57] mm/collapse: rebuild collapse on migration primitives

From: "David Hildenbrand (Arm)" <david@kernel.org>
Date: 2026-08-18 14:15:38
Also in: bpf, linux-kselftest, linux-mm, lkml

On 8/17/26 15:38, Kiryl Shutsemau wrote:
On Mon, Aug 17, 2026 at 09:52:13AM +0100, Lorenzo Stoakes (ARM) wrote:
quoted
We have a THP cabal meeting every couple of weeks where it would have been
useful for you to raise this first.
Fair -- though my invite is on my old @linux.intel.com address.  Could
you forward it to kas@kernel.org?
quoted
In any case - this series is not something we'd consider at the moment,
even broken into parts.

David and I have put THP into feature freeze - until the codebase is
subtantially improved we're not really interested in seeing significant
development.

The technical debt is substantial and has to be paid down first.

See [0] for a rough list of TODOs in this regard.
I read the TODO list and I'll pick from it -- though I notice the
technical debt section includes "Literally all of the code in
mm/huge_memory.c and mm/khugepaged.c", which I'd argue this series is a
fairly committed attempt at :)

One clean up I wanted to do is consolidate code by functionality, not by
the THP/non-THP split.  Move all page fault handler code into mm/fault.c,
unmap code into mm/zap.c, fork's copying into mm/fork.c -- mirroring
kernel/fork.c, so the mm half of a subsystem sits under the same name.
Large folios are an integral part of mm nowadays and I don't think we
benefit from keeping THP in a separate file.  It is also an opportunity to
shift away from mm/memory.c being a kitchen sink.

David and I talked about this at LSF/MM. 
Ah, I missed the context in my other reply. Lorenzo already had some patches at
some point to split up mm/memory.c into better chunks that will also better help
our subcomponent maintenance model.

I think the challenge is how to handle huge_memory.c, because ideally, we'd not
have these stupid callbacks into huge_memory.c once we make PMDs just a
first-class citizen.

This is, unfortunately, also something that needs more thought, because we don't
want to end up moving stuff back and forth.

-- 
Cheers,

David
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help