+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
