Re: Memory tiering with DAMON/DAMOS auto-tuning

[SJ Park <sj@kernel.org>]

On Thu, 1 Oct 2026 15:08:38 +0300 Anton Gavriliuk <antosha20xx@gmail.com> wrote:

> With your support, my progress tremendously faster than I expected :-)

Thank you.  The pleasure is mine :)

> 
> Moving forward.
> 
> In my VCF9.1-like example Demote/Promote bandwidth is limited by admin
> up to 8GB/s.
> 
> With CXL/PCIe 6.0 it may require moving pages between tiers 10's GB/s.
> In this case, kdamond single CPU core limited or can use more CPU
> cores if/when required ?
> 
> ~1 year ago I played with AMD Zen5 9455 and 12 channels 6400 MT/s DDR5
> DRAM, single thread core-to-local-memory bandwidth was ~49 GB/s.

It is basically limited to single CPU core per kdamond.  You could split memory
into multiple address ranges and assign kdamon per the range to utilize multi
CPUs, if needed.  SK Hynix [1] was using such an approach.

That said, I'm personally curious if such fast migration is really needed in
the real world workload.  I assume the real production workload would have
stable access pattern but only occasionally get access pattern changes.
Sometimes temporal and rapid access pattern change could also be made.  But for
such temporal pattern change, doing migration would only be costy, since the
data that suddenly hot could be soon be cold.  And reliability is important in
production.  Hence I was thinking slowly making the balance is better than too
quickly and reactively making migrations that will turn out to be no really
needed.

That said, if you want to test faster migration speed, the multiple kdamonds
usage could be one way to test.  If it turns out it is really needed and
splitting address ranges has problems, we can consider adding DAMOS feature for
utilizing multiple CPUs for faster migrations.

[1] https://sched.co/2913n


Thanks,
SJ

[...]