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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <aMnedTTmmpuvDxzt@gourry-fedora-PF4VCD3F>
Date: Tue, 16 Sep 2025 18:02:29 -0400
From: Gregory Price <gourry@...rry.net>
To: David Rientjes <rientjes@...gle.com>
Cc: Matthew Wilcox <willy@...radead.org>, 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,
	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 Tue, Sep 16, 2025 at 12:45:52PM -0700, David Rientjes wrote:
> > 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.
> > 
...
> 
> I've been pretty focused on the promotion story here rather than demotion 
> because of how responsive it needs to be.  Harvesting the page table 
> accessed bits or waiting on a sliding window through NUMA Balancing (even 
> NUMAB=2) is not as responsive as needed for very fast promotion to top 
> tier memory, hence things like the CHMU (or PEBS or IBS etc).
> 

I feel the need to throw out there that we need to set some kind of
baseline for comparison that isn't simply comparing new hotness tracking
stuff against "Doing Nothing".

For example, if we assume MGLRU is the default, we probably want to
compare against some kind of simplistic system that is essentially:

if tier0 has bandwidth room, and
	if tier1 is bandwidth pressured, then
		promote a chunk from tier1 youngest generation LRU
		("hottest") and demote a chunk from tier0 older LRU
		("coldest") [if there's no space available].

Active bandwidth utilization numbers are still a little hard to come
by, but a system like above could be implemented largely in userland
with a few tweaks to reclaim.

~Gregory