Re: [Linux Memory Hotness and Promotion] Notes from June 5, 2025

[Bharata B Rao <bharata@amd.com>]

Hi David,

Thanks for the detailed summary.

On 18-Jun-25 9:12 AM, David Rientjes wrote:
> Hi everybody,
> 
> Here are the notes from the last Linux Memory Hotness and Promotion call
> that happened on Thursday, June 5.  Thanks to everybody who was involved!
> 
> These notes are intended to bring people up to speed who could not attend
> the call as well as keep the conversation going in between meetings.
> 
> ----->o-----
> I recapped the previous instance and discussion around asynchronous page
> promotion driven through a kthread.  I also discussed the previous chat
> about trade-offs around isolated folio lists vs pfn based tracking of
> memory to migrate.
> 
> Bharata said that tracking pfns were much easier since they are
> stateless.  We don't need about doing refcounts or isolating too many
> pages.  Based on the latest iteration of the patch series, he converted
> this to use pfn based tracking because we don't want to keep memory
> isolated for too long.  Previous attempts isolated these folios at the
> time of page fault and then batch migrating them later.
> 
> Now, during page fault, we grab the pfn of the folio that has been
> misplaced and push that into a migrator subsystem -- a very simple
> subsystem that stores pfns pushed to it (NUMA Balancing as currently
> the first/only source) in a per-node list for the target node.  This is
> coupled with a per-node kthread that routinely scans the list and
> migrates the folio to the target node.  Work was underway to address
> some contention issue if there are multiple sources of these pfns to
> migrate (moving away from a mutex).
> 
> ----->o-----
> Wei Xu asked about the pfn based tracking and how this would handle
> multiple sources of memory hotness with additional information without a
> lot of overhead.  Bharata noted for locality based migration there was no
> need for additional information.  For hot page tracking, like with page
> table scanning or with CHMU, then we'd need more information later.
> 
> Wei suggested generalizing this now so that it is easily extensible later
> while still acknowledging that the metadata associated with previous
> kpromoted patch series was very large.  He suggested a virtual map that
> could be sparsely populated indexed by pfn.  Bharata acked that the
> information stored here should be concise and precised.  This would be a
> future extension, however.

I have posted the next version which maintains per-PFN/page information 
as part of extended page flags:

https://lore.kernel.org/linux-mm/20250616133931.206626-1-bharata@amd.com/

Regards,
Bharata.