linux-kernel - Re: [RFC PATCH V1 00/13] mm: slowtier page promotion based on PTE A bit

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a157a899-81b5-4098-8405-89ab899cdc68@amd.com>
Date: Fri, 21 Mar 2025 12:18:07 +0530
From: Raghavendra K T <raghavendra.kt@....com>
To: AneeshKumar.KizhakeVeetil@....com, Hasan.Maruf@....com,
 Michael.Day@....com, akpm@...ux-foundation.org, bharata@....com,
 dave.hansen@...el.com, david@...hat.com, dongjoo.linux.dev@...il.com,
 feng.tang@...el.com, gourry@...rry.net, hannes@...xchg.org,
 honggyu.kim@...com, hughd@...gle.com, jhubbard@...dia.com,
 jon.grimm@....com, k.shutemov@...il.com, kbusch@...a.com,
 kmanaouil.dev@...il.com, leesuyeon0506@...il.com, leillc@...gle.com,
 liam.howlett@...cle.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 mgorman@...hsingularity.net, mingo@...hat.com, nadav.amit@...il.com,
 nphamcs@...il.com, peterz@...radead.org, riel@...riel.com,
 rientjes@...gle.com, rppt@...nel.org, santosh.shukla@....com,
 shivankg@....com, shy828301@...il.com, sj@...nel.org, vbabka@...e.cz,
 weixugc@...gle.com, willy@...radead.org, ying.huang@...ux.alibaba.com,
 ziy@...dia.com, Jonathan.Cameron@...wei.com, alok.rathore@...sung.com,
 yuzhao@...gle.com
Subject: Re: [RFC PATCH V1 00/13] mm: slowtier page promotion based on PTE A
 bit

+Yu Zhao

Realized we had not CCed him earlier

On 3/21/2025 3:20 AM, Davidlohr Bueso wrote:
> On Thu, 20 Mar 2025, Raghavendra K T wrote:
> 
>>> Does NUMAB2 continue to exist? Are there any benefits in having two
>>> sources?
>>>
>>
>> I think there is surely a benefit in having two sources.
> 
> I think I was a bit vague. What I'm really asking is if the scanning is
> done async (kmmscand), should NUMAB2 also exist as a source and also feed
> into the migrator? Looking at it differently, I guess doing so would allow
> additional flexibility in choosing what to use.
> 

Not exactly. Since NUMAB2 is bringing accurate timestamp information and
additional migration throttling logic on top of NUMAB1,
we can just keep NUMAB1, but borrowing migration throttling from NUMAB2
and make sure that migration is asynchronous.

This is with the assumption that kmmscand will be able to detect the
exact target node in most of the cases, and additional flexibility
of toptier balancing come from NUMAB1.


>> NUMAB2 is more accurate but slow learning.
> 
> Yes. Which is also why it is important to have demotion in the picture to
> measure the ping pong effect. LRU based heuristics work best here.
> 

+1

>> IBS: No scan overhead but we need more sampledata.
> 
>> PTE A bit: more scanning overhead (but was not much significant to
>> impact performance when compared with NUMAB1/NUMAB2, rather it was more
>> performing because of proactive migration) but has less accurate data on
>> hotness, target_node(?).
>>
>> When system is more stable, IBS was more effective.
> 
> IBS will never be as effective as it should be simply because of the lack
> of time decay/frequency (hence all that related phi hackery in the 
> kpromoted
> series). It has a global view of memory, it should beat any sw scanning
> heuristics by far but the numbers have lacked.
> 
> As you know, PeterZ, Dave Hansen, Ying and I have expressed concerns about
> this in the past. But that is not to say it does not serve as a source,
> as you point out.
> 
> Thanks,
> Davidlohr