On Tue, Aug 18, 2026 at 04:15:27PM +0200, David Hildenbrand (Arm) wrote: > 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.
Ah yeah I kinda lost those but indeed doing this is a good idea. I should try to dig those out again or look again when I have a chance... > > 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. Yes and another point and I think it's one that Kiryl also gets at is - can we _please_ stop pretending huge folios == THP == what the page cache does == page special cases like DAX? :) I think Matthew had ideas (TM) about separating out CONFIG_THP from that stuff but that's another way in which we can unwend some of the horrors. > > This is, unfortunately, also something that needs more thought, because we > don't > want to end up moving stuff back and forth. Yeah annoyingly it's not all straightforward. I wonder if actually gauging off of what series often touch in patches might be a good way of figuring out how to separate, funnily enough (certainly for mm-next conflict resolution purposes anyway). > > -- > Cheers, > > David -- Cheers, Lorenzo
