linux-kernel - Re: [RFC PATCH v2 0/8] mm: Hot page tracking and promotion infrastructure

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aMGg9AOaCWfxDfqX@gourry-fedora-PF4VCD3F>
Date: Wed, 10 Sep 2025 12:01:56 -0400
From: Gregory Price <gourry@...rry.net>
To: Matthew Wilcox <willy@...radead.org>
Cc: Bharata B Rao <bharata@....com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, Jonathan.Cameron@...wei.com,
	dave.hansen@...el.com, hannes@...xchg.org,
	mgorman@...hsingularity.net, mingo@...hat.com, peterz@...radead.org,
	raghavendra.kt@....com, riel@...riel.com, rientjes@...gle.com,
	sj@...nel.org, weixugc@...gle.com, ying.huang@...ux.alibaba.com,
	ziy@...dia.com, dave@...olabs.net, nifan.cxl@...il.com,
	xuezhengchu@...wei.com, yiannis@...corp.com,
	akpm@...ux-foundation.org, david@...hat.com, byungchul@...com,
	kinseyho@...gle.com, joshua.hahnjy@...il.com, yuanchu@...gle.com,
	balbirs@...dia.com, alok.rathore@...sung.com
Subject: Re: [RFC PATCH v2 0/8] mm: Hot page tracking and promotion
 infrastructure

On Wed, Sep 10, 2025 at 04:39:16PM +0100, Matthew Wilcox wrote:
> On Wed, Sep 10, 2025 at 08:16:45PM +0530, Bharata B Rao wrote:
> > This patchset introduces a new subsystem for hot page tracking
> > and promotion (pghot) that consolidates memory access information
> > from various sources and enables centralized promotion of hot
> > pages across memory tiers.
> 
> Just to be clear, I continue to believe this is a terrible idea and we
> should not do this.  If systems will be built with CXL (and given the
> horrendous performance, I cannot see why they would be), the kernel
> should not be migrating memory around like this.

I've been considered this problem from the opposite approach since LSFMM.

Rather than decide how to move stuff around, what if instead we just
decide not to ever put certain classes of memory on CXL.  Right now, so
long as CXL is in the page allocator, it's the wild west - any page can
end up anywhere.

I have enough data now from ZONE_MOVABLE-only CXL deployments on real
workloads to show local CXL expansion is valuable and performant enough
to be worth deploying - but the key piece for me is that ZONE_MOVABLE
disallows GFP_KERNEL.  For example: this keeps SLAB meta-data out of 
CXL, but allows any given user-driven page allocation (including page
cache, file, and anon mappings) to land there.

I'm hoping to share some of this data in the coming months.

I've yet to see any strong indication that a complex hotness/movement
system is warranted (yet) - but that may simply be because we have
local cards with no switching involved. So far LRU-based promotion and
demotion has been sufficient.

It seems the closer to random-access the access pattern, the less
valuable ANY movement is. Which should be intuitive.  But, having
CXL beats touching disk every day of the week.

So I've become conflicted on this work - but only because I haven't seen
the data to suggest such complexity is warranted.

~Gregory