Re: [PATCH] MAINTAINERS: add mm THP section

[David Hildenbrand <david@redhat.com>]

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