On 8/17/26 15:38, Kiryl Shutsemau wrote: > On Mon, Aug 17, 2026 at 09:52:13AM +0100, Lorenzo Stoakes (ARM) wrote: >> 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 [email protected]? > >> 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
