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: <40e69993-e83b-4019-943f-ab90a43eb0de@lucifer.local>
Date: Thu, 24 Apr 2025 19:11:03 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...hat.com>, 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 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.