linux-kernel - Re: [PATCH] Revert "mm, hugetlb: remove hugepages_treat_as

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: <aOgDTc-xix66RxXc@tiehlicka>
Date: Thu, 9 Oct 2025 20:47:41 +0200
From: Michal Hocko <mhocko@...e.com>
To: Gregory Price <gourry@...rry.net>
Cc: David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
	corbet@....net, muchun.song@...ux.dev, osalvador@...e.de,
	akpm@...ux-foundation.org, hannes@...xchg.org, laoar.shao@...il.com,
	brauner@...nel.org, mclapinski@...gle.com, joel.granados@...nel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	Mel Gorman <mgorman@...e.de>,
	Alexandru Moise <00moses.alexander00@...il.com>,
	Mike Kravetz <mike.kravetz@...cle.com>,
	David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH] Revert "mm, hugetlb: remove hugepages_treat_as_movable
 sysctl"

On Thu 09-10-25 11:29:57, Gregory Price wrote:
> On Thu, Oct 09, 2025 at 08:14:22AM +0200, Michal Hocko wrote:
> > On Wed 08-10-25 12:31:22, Gregory Price wrote:
> > > > I'm not quite clear yet on the use case, though. If all the user allocations
> > > > end up fragmenting the memory, there is also not a lot of benefit to be had
> > > > from that zone long term.
> > > >
> > > 
> > > The only real use case i've seen is exactly: 
> > >  - Don't want random GFP_KERNEL to land there
> > >  - Might want it to be pinnable
> > > 
> > > I think that covers what you've described above.
> > > 
> > > But adding an entire zone felt a bit heavy handed.  Allowing gigantic in
> > > movable seemed less - immediately - offensive.
> > 
> > The question is whether we need a full zone for that or we can control
> > those allocation constrains on per memory block bases to override
> > otherwise default. So it wouldn't be MOVABLE but rather something like
> > USER zone.
> 
> 
> Mild ignorance here - but I don't think the buddy allocator currently
> differentiates chunks of memory based on block membership, it just eats
> folios from certain zones/nodes.

No ignorance on your end. As I've said this is not fully thought through
idea. Memory block was meant to be userspace configurable unit.
Internally this would need to be mapped into migrate type or something
like that.
-- 
Michal Hocko
SUSE Labs