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: <D9F4G2PS9ACB.20J8ON7DQU7GK@nvidia.com>
Date: Thu, 24 Apr 2025 15:38:39 -0400
From: "Zi Yan" <ziy@...dia.com>
To: "David Hildenbrand" <david@...hat.com>, "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 Thu Apr 24, 2025 at 2:44 PM EDT, David Hildenbrand wrote:
> 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.

I agree that we should not have per-order knobs like now, but letting
kernel to figure out everything might be a stretch since it might
requires a lot of profiling to get some information about user program
behaviors. Some hints like madvise(MADV_{NO}HUGEPAGE) could save a lot
of profilings. Maybe your auto mode includes such hints.

But pagecache does not have such hints, maybe file accesses gives good
hints already. Matthew, what is your take on this? Hints or no hints?
Or anon mem is different for this aspect?

>
> 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.

Yeah, I guess we want to be able to distribute patches to different
sets of experts, otherwise all patches will be sent to a large group
of the same people. That might be inefficient.

-- 
Best Regards,
Yan, Zi