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

[Davidlohr Bueso <dave@stgolabs.net>]

On Fri, 14 Mar 2025, Jonathan Cameron wrote:

>On Sun, 16 Feb 2025 14:49:50 +0800
>"Huang, Ying" <ying.huang@linux.alibaba.com> wrote:

>> 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.,
>

Right, I was also thinking along those lines. Hot pages could be fed right into
kpromoted (with the appropriate interface for 'phi' of course), then kicked to
do the migration. This already has the frequency, and the destination node so
no guessing as to where the page should be placed.

So this makes me wonder kmmscand vs NUMAB=2... should both co-exist? Doubling
the scanning overhead, so I think not (albeit non mapped page cache pages).
The original data from kmmscand is with a busted nid selection, but now Raghu
has a proposed some heuristics, so I am curious what kind of numbers come up
in terms of accuracy and performance vs a NUMAB=2 migration offload.

>Absolutely agree that might be the approach, but with some form of back pressure
>as for at least some approaches it is much cheaper to find a find a few hot
>pages than to find lots of them.  More complex if you want a few of the very hottest
>or just hotter than X.

Yeah, also cases like different CXL type3 devices with different access latencies
both saying here's what's hot.

Thanks,
Davidlohr