Re: [PATCH 0/7] Accelerate page migration with batch copying and hardware offload

[Huang, Ying]

"David Hildenbrand (Arm)" <david@xxxxxxxxxx> writes:

> On 5/12/26 04:35, Huang, Ying wrote:
>> "David Hildenbrand (Arm)" <david@xxxxxxxxxx> writes:
>> 
>>> On 4/28/26 17:50, Shivank Garg wrote:
>>>> This is the fifth RFC of the patchset to enhance page migration by
>> 
>> [snip]
>>>
>>>>
>>>> 3. Per-caller offload selection: Today eligibility is by migrate_reason
>>>>    only. Some are latency-tolerant, others may be not. Is reason the
>>>>    right granularity, or do we want a per-caller hint?
>>>
>>> Isn't it sufficient to just do it based on the #folios or sth like that?
>>>
>>> If someone migrates a handful of folios, latency is likely more important (and
>>> batching less beneficial).
>>>
>>> I'd assume when migrating many folios, batching could just always be done. Or
>>> what's the concern?
>> 
>> IIUC, for callers like migrate_pages syscall, it's possible that almost all
>> folios of a process are passed to migrate_pages().  However, I think that
>> we still need to keep the folio inaccessible time reasonable.
>
> Wouldn't we still want to process them in batches, only affecting folios in a
> batch at one point in time, not the whole address space?

Sorry, my previous reply was confusing.  Let me try to be clearer.

I think we need to distinguish between two kinds of latency.  One is the
latency to migrate folios; the other is the latency during which a core
cannot access memory (while unmapped during migration).

IIUC, most users want the second one to be as short as possible.  One
possible user that does not care as much is the folio demoter, which
migrates cold higher-tier folios to lower tier after they have not been
accessed for some time.

---
Best Regards,
Huang, Ying