linux-kernel - Re: [PATCH] MAINTAINERS: add mm THP section

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc0b7131-ae02-4675-9a21-23d432c20f19@redhat.com>
Date: Thu, 24 Apr 2025 20:44:53 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Matthew Wilcox <willy@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Zi Yan <ziy@...dia.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, Nico Pache
 <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: add mm THP section

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