linux-kernel - Re: [RFC PATCH v0 0/2] Batch migration for NUMA balancing

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: <aC6VIG7GPnqr3ug-@gourry-fedora-PF4VCD3F>
Date: Wed, 21 May 2025 23:08:16 -0400
From: Gregory Price <gourry@...rry.net>
To: SeongJae Park <sj@...nel.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,
	weixugc@...gle.com, willy@...radead.org,
	ying.huang@...ux.alibaba.com, ziy@...dia.com, dave@...olabs.net,
	nifan.cxl@...il.com, joshua.hahnjy@...il.com,
	xuezhengchu@...wei.com, yiannis@...corp.com,
	akpm@...ux-foundation.org, david@...hat.com
Subject: Re: [RFC PATCH v0 0/2] Batch migration for NUMA balancing

On Wed, May 21, 2025 at 11:45:52AM -0700, SeongJae Park wrote:
> Hi Bharata,
> 
> On Wed, 21 May 2025 13:32:36 +0530 Bharata B Rao <bharata@....com> wrote:
> 
> > Hi,
> > 
> > This is an attempt to convert the NUMA balancing to do batched
> > migration instead of migrating one folio at a time. The basic
> > idea is to collect (from hint fault handler) the folios to be
> > migrated in a list and batch-migrate them from task_work context.
> > More details about the specifics are present in patch 2/2.
> > 
> > During LSFMM[1] and subsequent discussions in MM alignment calls[2],
> > it was suggested that separate migration threads to handle migration
> > or promotion request may be desirable. Existing NUMA balancing, hot
> > page promotion and other future promotion techniques could off-load
> > migration part to these threads. Or if we manage to have a single
> > source of hotness truth like kpromoted[3], then that too can hand
> > over migration requests to the migration threads. I am envisaging
> > that different hotness sources like kmmscand[4], MGLRU[5], IBS[6]
> > and CXL HMU would push hot page info to kpromoted, which would
> > then isolate and push the folios to be promoted to the migrator
> > thread.
> 
> I think (or, hope) it would also be not very worthless or rude to mention other
> existing and ongoing works that have potentials to serve for similar purpose or
> collaborate in future, here.
> 
> DAMON is designed for a sort of multi-source access information handling.  In
> LSFMM, I proposed[1] damon_report_access() interface for making it easier to be
> extended for more types of access information.  Currenlty damon_report_access()
> is under early development.  I think this has a potential to serve something
> similar to your single source goal.
> 

It seems to me that DAMON might make use of the batch migration
interface, so if you need any changes or extensions, it might be good
for you (SJ) to take a look at that for us.

~Gregory