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: <55c51f34-b41d-49b2-96a2-dcc5f425f966@amd.com>
Date: Tue, 27 May 2025 14:23:27 +0530
From: Bharata B Rao <bharata@....com>
To: "Huang, Ying" <ying.huang@...ux.alibaba.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 Jonathan.Cameron@...wei.com, dave.hansen@...el.com, gourry@...rry.net,
 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, willy@...radead.org,
 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 26-May-25 2:16 PM, Huang, Ying wrote:
> Hi, Bharata,
> 
> Bharata B Rao <bharata@....com> writes:
> 
>> 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.
> 
> What is the expected benefit of the change?

Initially it is about cleanliness and separation of migration into its 
own thread/sub-system.

> 
> For code reuse, we can use migrate_misplaced_folio() or
> migrate_misplaced_folio_batch() in various promotion path.

That's what I have done in this patchset at least. We thought we could 
go full length and off-load migration to its own thread.

> 
> For workload latency influence, per my understanding, PTE scanning is
> much more serious than migration.  Why not start from that?

Raghu's PTE A bit scanning is one effort towards that (Removing PTE 
scanning from task context.

Regards,
Bharata.