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: <87cybua0fi.fsf@DESKTOP-5N7EMDA>
Date: Tue, 27 May 2025 17:05:21 +0800
From: "Huang, Ying" <ying.huang@...ux.alibaba.com>
To: Bharata B Rao <bharata@....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

Bharata B Rao <bharata@....com> writes:

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

Even if we migrate pages in another thread, the migrated pages will be
unmapped, copied, remapped during migrating.  That is, the workload
threads may be stalled to wait for migrating.  So, we need to measure
the real benefit firstly.

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

---
Best Regards,
Huang, Ying