Re: [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure

[Bharata B Rao <bharata@amd.com>]

On 12-Sep-26 2:38 AM, Joshua Hahn wrote:
> Hi Bharata,
> 
> We've been testing pghot in a Meta kernel with worklaods to try and see
> what the performance characteristics look like. I wanted to report
> some of the findings that we've found in our testing. Note that these
> results are from a modified kernel that has my tiered memcg series [1]
> backported, as well as Gregory's numa balancing scanning fixes [2]
> as well. 

Hi Joshua,

Thanks for testing pghot with your workload!

> 
> - Without tuning and using the default tunables that pghot comes with,
>   we've found around a slight performance regression against raw NUMAB2.
>   This was being run on a host with 750G DRAM and 250G CXL.

pghot promotes on 2nd access by default since pghot_freq_threshold is 2
by default. This will result in slower promotions compared to NUMAB2
which promotes on 1st access. Could you please try with setting
pghot_freq_threshold to 1? I think I should make the default as 1 going
forward.

In any case, will it be possible to provide more information on what your
workloads are, and the exact performance metrics? Any representative workload
that can be substituted to reproduce this behaviour can also help.

And when you say slight perf regression, how much is it exactly?

> - However, we've found lower pgscan_direct, pgpromote, and pgdemote
>   rates as well.
> - We've seen PSI dramatically drop on the host as well as the promotion
>   happens asynchronously. 

That's good to see.

> - I also found a bug where the kmigrated thread isn't created for nodes
>   that are onlined later after boot, like CXL nodes that get onlined
>   with memory later on. I've been using a small hack commit in
>   pghot_memhp_callback that just checks for the MEM_ONLINE case and
>   spawns a kmigrated thread.

I will take care of this scenario (CXL node online after boot) in my next posting.

> 
> Finally, we've seen some issues with pghot causing userspace crashes,
> which leads us to believe that there might be some bugs that manifest
> in userspace as well (we have not been able to find out where in pghot
> these bugs are introduced).

That's something I have never seen till now with any of the benchmarks that I
have run. Any kernel messages attributing the failure to pghot? Anything
attributable to access reporting or  kmigrated threads?

Any clues from coredump or gdb debug of userspace crash?

Were you running your workloads as part of a non-root memcg?

Do you see these failures without [1] and/or [2] ?

> 
> Thanks for working on pghot!
> Joshua
> 
> [1] https://lore.kernel.org/all/20260807202059.2620949-1-joshua.hahnjy@gmail.com/
> [2] https://lore.kernel.org/all/20260911001826.2109390-1-gourry@gourry.net/

Regards,
Bharata.