linux-kernel - Re: [RFC PATCH v1 3/7] mm: Hot page tracking and promotion

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: <871ppde4b2.fsf@DESKTOP-5N7EMDA>
Date: Fri, 15 Aug 2025 09:56:01 +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>,  <xuezhengchu@...wei.com>,  <yiannis@...corp.com>,
  <akpm@...ux-foundation.org>,  <david@...hat.com>,  <byungchul@...com>,
  <kinseyho@...gle.com>,  <joshua.hahnjy@...il.com>,  <yuanchu@...gle.com>,
  <balbirs@...dia.com>
Subject: Re: [RFC PATCH v1 3/7] mm: Hot page tracking and promotion

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

> This introduces a sub-system for collecting memory access
> information from different sources. It maintains the hotness
> information based on the access history and time of access.
>
> Additionally, it provides per-lowertier-node kernel threads
> (named kpromoted) that periodically promote the pages that
> are eligible for promotion.
>
> Sub-systems that generate hot page access info can report that
> using this API:
>
> int pghot_record_access(u64 pfn, int nid, int src,
> 			unsigned long time)
>
> @pfn: The PFN of the memory accessed
> @nid: The accessing NUMA node ID
> @src: The temperature source (sub-system) that generated the
>       access info
> @time: The access time in jiffies

How will the page hotness information gather with NUMA balancing hint
page fault be expressed with this interface?

> Some temperature sources may not provide the nid from which
> the page was accessed. This is true for sources that use
> page table scanning for PTE Accessed bit. For such sources,
> the default toptier node to which such pages should be promoted
> is hard coded.
>
> Also, the access time provided some sources may at best be
> considered approximate. This is especially true for hot pages
> detected by PTE A bit scanning.
>
> The hot PFN records are stored in hash lists hashed by PFN value.
> The PFN records that are categorized as hot enough to be promoted
> are maintained in a per-lowertier-node max heap from which
> kpromoted extracts and promotes them.
>
> Each record stores the following info:
>
> struct pghot_info {
> 	unsigned long pfn;
>
> 	unsigned long last_update; /* Most recent access time */
> 	int frequency; /* Number of accesses within current window */
> 	int nid; /* Most recent access from this node */
>
> 	struct hlist_node hnode;
> 	size_t heap_idx; /* Position in max heap for quick retreival */
> };
>
> The way in which a page is categorized as hot enough to be
> promoted is pretty primitive now.
>

[snip]

---
Best Regards,
Huang, Ying