Re: [LSF/MM/BPF TOPIC] Unifying sources of page temperature information - what info is actually wanted?

["Huang, Ying" <ying.huang@linux.alibaba.com>]

Hi, Bharata,

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

> On 31-Jan-25 6:39 PM, Jonathan Cameron wrote:
>> On Fri, 31 Jan 2025 12:28:03 +0000
>> Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
>> 
>>>> Here is the list of potential discussion points:
>>> ...
>>>
>>>> 2. Possibility of maintaining single source of truth for page hotness that would
>>>> maintain hot page information from multiple sources and let other sub-systems
>>>> use that info.
>>> Hi,
>>>
>>> I was thinking of proposing a separate topic on a single source of hotness,
>>> but this question covers it so I'll add some thoughts here instead.
>>> I think we are very early, but sharing some experience and thoughts in a
>>> session may be useful.
>> Thinking more on this over lunch, I think it is worth calling this
>> out as a
>> potential session topic in it's own right rather than trying to find
>> time within other sessions.  Hence the title change.
>> I think a session would start with a brief listing of the
>> temperature sources
>> we have and those on the horizon to motivate what we are unifying, then
>> discussion to focus on need for such a unification + requirements
>> (maybe with a straw man).
>
> Here is a compilation of available temperature sources and how the
> hot/access data is consumed by different subsystems:

Thanks for your information!

> PA-Physical address available
> VA-Virtual address available
> AA-Access time available
> NA-accessing Node info available
>
> I have left the slot blank for those which I am not sure about.
> ==================================================
> Temperature		PA	VA	AA	NA
> source
> ==================================================
> PROT_NONE faults	Y	Y	Y	Y
> --------------------------------------------------
> folio_mark_accessed()	Y		Y	Y
> --------------------------------------------------
> PTE A bit		Y	Y	N	N

We can get some coarse-grained AA from PTE A bit scanning.  That is, the
page is accessed at least once between two rounds of scanning.  The AA
is less the scanning interval.  IIUC, the similar information is
available in Yuanchu's MGLRU periodic aging series [1].

[1] https://lore.kernel.org/all/20221214225123.2770216-1-yuanchu@google.com/

> --------------------------------------------------
> Platform hints		Y	Y	Y	Y
> (AMD IBS)
> --------------------------------------------------
> Device hints		Y
> (CXL HMU)
> ==================================================
>
> And here is an attempt to compile how different subsystems
> use the above data:
> ==============================================================
> Source			Subsystem		Consumption
> ==============================================================
> PROT_NONE faults	NUMAB		NUMAB=1 locality based
> via process pgtable			balancing
> walk					NUMAB=2 hot page
> 					promotion
> ==============================================================
> folio_mark_accessed()	FS/filemap/GUP	LRU list activation

IIUC, Gregory is working on a patchset to promote unmapped file cache
pages via folio_mark_accessed().

> ==============================================================
> PTE A bit via		Reclaim:LRU	LRU list activation,	
> rmap walk				deactivation/demotion
> ==============================================================
> PTE A bit via		Reclaim:MGLRU	LRU list activation,	
> rmap walk and process			deactivation/demotion
> pgtable walk
> ==============================================================
> PTE A bit via		DAMON		LRU activation,
> rmap walk				hot page promotion,
> 					demotion etc
> ==============================================================
> Platform hints		NUMAB		NUMAB=1 Locality based
> (AMD IBS)				balancing and
> 					NUMAB=2 hot page
> 					promotion
> ==============================================================
> Device hints		NUMAB		NUMAB=2 hot page
> 					promotion
> ==============================================================
> The last two are listed as possibilities.
>
> Feel free to correct/clarify and add more.

---
Best Regards,
Huang, Ying