Re: [PATCH] MAINTAINERS: add mm THP section

[David Hildenbrand]

On 24.04.25 20:11, Lorenzo Stoakes wrote:
> On Thu, Apr 24, 2025 at 06:57:22PM +0100, Matthew Wilcox wrote:
> > On Thu, Apr 24, 2025 at 12:16:32PM +0100, Lorenzo Stoakes wrote:
> > > As part of the ongoing efforts to sub-divide memory management
> > > maintainership and reviewership, establish a section for Transparent Huge
> > > Page support and add appropriate maintainers and reviewers.
> >
> > I'm quite queasy about this.  I'm doing my best to make "THP" disappear
> > as a concept.  How would you define what THP is?  Originally, it was
> > PMD-sized-and-aligned allocations, and some of the way we expose it to
> > userspace, that's still the interpretation.  But we also have folios which
> > are of some hardware-defined magic sizes, as well as (for filesystems,
> > at least) random other non-zero orders.
> >
> > Memory is just managed in variously sized quantities.  There should be
> > nothing magic about "THP", and I'm still annoyed at the anon-mem people
> > for baking various magic sizes into user-visible APIs.
>
> Right, but as it stands, we already separate out handling for a whole host
> of different THP things by file, which get_maintainers.pl knows nothing
> about.
>
> For:
>
> 	include/linux/huge_mm.h
> 	include/linux/khugepaged.h
> 	include/trace/events/huge_memory.h
> 	mm/huge_memory.c
> 	mm/khugepaged.c
> 	tools/testing/selftests/mm/khugepaged.c
> 	tools/testing/selftests/mm/split_huge_page_test.c
> 	tools/testing/selftests/mm/transhuge-stress.c
>
> This is not a philosophical position as to where we _might go_ in future,
> or how we might decide to treat varying folio sizes going forward, but
> rather a purely practical step so these files get seen by people and the
> de-facto maintainer is ack'ed as such.
>
> When we get to the point where we can simply treat all as the same, we can
> reflect as much in MAINTAINERS too, this is not set in stone.

Yeah, I think we all share the same long-term goal of not even having 
huge_memory.c anymore; it's simply not going to be special anymore.

My hope is that with the planned "auto" mode for anon (m)THP we'd be 
able to switch in the future as default to a "let MM manage all that, 
it's now smart enough", to slowly phase manual control it out. We still 
have to deal with the legacy Huge/PMD-mapped stats that keep annoying me.

Personally, I wouldn't mind moving it under MM core already, but for now 
this might be better to find the right reviewers. As you say, we can 
always adjust -- especially once huge_memory.c goes away because it will 
simply be memory.c, or whatever that file will be called then.

--
Cheers,

David / dhildenb