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: <20250522163024.56592-1-sj@kernel.org>
Date: Thu, 22 May 2025 09:30:23 -0700
From: SeongJae Park <sj@...nel.org>
To: Gregory Price <gourry@...rry.net>
Cc: SeongJae Park <sj@...nel.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,
	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, 21 May 2025 23:08:16 -0400 Gregory Price <gourry@...rry.net> wrote:

> 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.

I started this subthread not for batch migration but the long term goal.  I
took only a glance on the migration batching part, and I'm still trying to find
time to take more deep look on batch migration.

Nonetheless, yes, basically I believe DAMON and Bharata's works have great
opportunities to collaborate and use each other in a very productive ways.  I'm
especially very intersted in kpromoted's AMD IBS code, and trying to make DAMON
easier to be used for Bharata's works.

For batch migration interface, though, to be honest I don't find very clear
DAMON's usage of it, since DAMON does region-based sort of batched migration.
Again, I took only a glance on migration batching part and gonna take more time
to the details.

Meanwhile, if you saw some opportunities, and if you don't mind, it would be
very helpful if you can share your detailed view of the opportunity (how DAMON
could be better by using the migration batching in what way?).


Thanks,
SJ


> 
> ~Gregory