linux-kernel - Re: [LSF/MM/BPF TOPIC] Unifying sources of page temperature information

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: <f091e09a-1f39-48ee-8968-8f616d8102a6@amd.com>
Date: Mon, 17 Feb 2025 09:40:36 +0530
From: Bharata B Rao <bharata@....com>
To: "Huang, Ying" <ying.huang@...ux.alibaba.com>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc: Raghavendra K T <raghavendra.kt@....com>, linux-mm@...ck.org,
 akpm@...ux-foundation.org, lsf-pc@...ts.linux-foundation.org,
 gourry@...rry.net, nehagholkar@...a.com, abhishekd@...a.com,
 nphamcs@...il.com, hannes@...xchg.org, feng.tang@...el.com, kbusch@...a.com,
 Hasan.Maruf@....com, sj@...nel.org, david@...hat.com, willy@...radead.org,
 k.shutemov@...il.com, mgorman@...hsingularity.net, vbabka@...e.cz,
 hughd@...gle.com, rientjes@...gle.com, shy828301@...il.com,
 liam.howlett@...cle.com, peterz@...radead.org, mingo@...hat.com,
 nadav.amit@...il.com, shivankg@....com, ziy@...dia.com, jhubbard@...dia.com,
 AneeshKumar.KizhakeVeetil@....com, linux-kernel@...r.kernel.org,
 jon.grimm@....com, santosh.shukla@....com, Michael.Day@....com,
 riel@...riel.com, weixugc@...gle.com, leesuyeon0506@...il.com,
 honggyu.kim@...com, leillc@...gle.com, kmanaouil.dev@...il.com,
 rppt@...nel.org, dave.hansen@...el.com
Subject: Re: [LSF/MM/BPF TOPIC] Unifying sources of page temperature
 information - what info is actually wanted?

On 16-Feb-25 12:19 PM, Huang, Ying wrote:
>>>
>>> 1) Give me up to X hotish pages from a slow tier (greater than a specific measure
>>> of temperature)
> 
> Because the hot pages may be available upon page accessing (such PROT_NONE
> page fault), the interface may be "push" style instead of "pull" style,
> e.g.,
> 
> int register_hot_page_handler(void (*handler)(struct page *hot_page, int temperature));

Yes, push model appears natural to me given that there are producers who 
are themselves consumers as well.

Let's take an example of access being detected by PTE scan by DAMON 
first and LRU and hot page promotion subsystems have registered handlers 
for hot page info.

Now if hot page promotion handler gets called first and if it promotes 
the page, calling LRU registered handler still makes sense? May be not I 
suppose.

On the other hand if LRU subsystem handler gets first and it 
adjusts/modifies the hot page's list, it would still make sense to 
activate the hot page promotion handler to check for possible promotion.

Is this how you are envisioning the different consumers of hot page 
access info could work/cooperate?

Regards,
Bharata.