linux-kernel - Re: [PATCH v1 1/2] mm/vmscan: balance demotion allocation in alloc_demote

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: <20260110005229.1348817-1-joshua.hahnjy@gmail.com>
Date: Fri,  9 Jan 2026 16:52:28 -0800
From: Joshua Hahn <joshua.hahnjy@...il.com>
To: Bing Jiao <bingjiao@...gle.com>
Cc: Donet Tom <donettom@...ux.ibm.com>,
	linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	David Hildenbrand <david@...nel.org>,
	Michal Hocko <mhocko@...nel.org>,
	Qi Zheng <zhengqi.arch@...edance.com>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Axel Rasmussen <axelrasmussen@...gle.com>,
	Yuanchu Xie <yuanchu@...gle.com>,
	Wei Xu <weixugc@...gle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/2] mm/vmscan: balance demotion allocation in alloc_demote_folio()

On Fri, 9 Jan 2026 23:45:57 +0000 Bing Jiao <bingjiao@...gle.com> wrote:

> On Thu, Jan 08, 2026 at 06:14:02PM +0530, Donet Tom wrote:
> >
> > On 1/7/26 12:58 PM, Bing Jiao wrote:
> > > +	/* Randomly select a node from fallback nodes for balanced allocation */
> > > +	if (allowed_mask) {
> > > +		mtc->nid = node_random(allowed_mask);
> >
> >
> > This random selection can cause allocations to fall back to distant memory
> > even when the nearer demotion target has sufficient free memory, correct?
> > Could this also lead to increased promotion latency?
> 
> Hi Donet,
> 
> Thanks for your questions.
> 
> Yes, the random selection could select a distant node and lead to
> incresed promotion latency.
> 
> I just realized that the the fallback allocation should not weighted
> by a single metric, such as node distance, capacity, free space.

Hello Bing, I hope you are doing well!

Yes -- this is also what I believe, and I think this idea of "how should we
select demotion / allocation targets" is something that is a difficult problem
(and one that may not have a single solution that "just works").

It's also a question that I have been thinking about, and what was discussed
in part at LSFMMBPF last year. At the time, I made some auto-tuning weights [1]
for weighted interleave based on bandwidth capacity, since the main benefit of
weighted interleave is to distribute memory accesses across multiple nodes
to maximize how much bandwidth the system can use at once. A follow-up was to
think about how these weights could change over time, and what heuristics
should be used to determine how the weights are selected.

Ultimately, we agreed that the heuristics should probably be delegated to
userspace, since there are just so many scenarios that could change what
metrics should take priority. (Jonathan Corbet wrote a great summary of the
discussion in an LWN article [2])

Coming back to this patchset, I think that all of the ideas above apply
nicely here as well. What nodes should be selected for demotion and how they
should be weighted is a difficult question, and one that is probably best
answered by userspace and what workload they expect to use on their specific
system.

What I do believe though, is that an unweighted random selection / round-robin
approach to selecting demotion targets might lead to some unexpected
performance implications.

> We need a thoroughly study before changing alloc_demote_folio().

So I think this is the way to go : -)
Although, I'm not actively exploring this at the moment ;)

Please let me know what you think, I hope you have a great day!
Joshua

[1] https://lore.kernel.org/all/20250109185048.28587-1-joshua.hahnjy@gmail.com/
[2] https://lwn.net/Articles/1016842/