Re: [Linux Memory Hotness and Promotion] Notes from October 22, 2026

[SJ Park <sj@kernel.org>]

Hi David,


Thank you for sharing these nice notes!  I unforunately keep being unable to
join the meeting, so these notes are very helpful.

On Fri, 23 Oct 2026 20:14:53 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:

> Hi everybody,
> 
> Here are the notes from the last Linux Memory Hotness and Promotion call
> that happened on Thursday, October 22.  Thanks to everybody who was 
> involved!
> 
> These notes are intended to bring people up to speed who could not attend 
> the call as well as keep the conversation going in between meetings.
[...]
> Davidlohr noted that this matched his expectation and that he is working 
> on upstreaming the CHMU support as a CXL driver, currently using DAMON as 
> its backend.  He'll then wait to see the outcome of the other patch series 
> in parallel.  Jonathan questioned how integration with DAMON would be done 
> to eventually support the asynchronous promotion stuff.  Davidlohr said 
> this would be done in the most generic way as possible.  CHMU has a 
> natural interface with ranges and large continguous chunks of memory that 
> can be passed to any interface.  If pghot is confined to the NUMA 
> Balancing aspects, then CHMU wouldn't be integrated with it.  Jonathan 
> asked if we're really getting large contiguous chunks of memory from the 
> CHMU and Davidlohr said this is what he is seeing in his evaluation.

Makes sense to me.  If CHMU can find address ranges of hot memory, it could
directly ask DAMOS to migrate those to a specific node.  DAMOS does not provide
such interface for now.  We could implement new API like damos_add_folios(),
which I proposed at LSFMMBPF'25.  For CHMU, I think it could be easier if the
API receives address ranges instead of folios.

Yet another idea is let users ask DAMON to do everything.  That is, DAMON will
turn on CHMU, get the hot memory information from it, and do the migration all
by itself.  DAMON sysfs ABI would need to be extended for CHMU configuration.

Both look doable to me.  Davidlohr may have a much better idea.  In any case, I
will be happy to help as always.  Please don't hesitate to reach out even if it
is only for internal prototyping that doesn't pursue upstreaming.

> 
> Bharata suggested it may be difficult to get the configuration of DAMON 
> correct, this is a complex undertaking.  If the only way to use CHMU is 
> through DAMON, this may be challenging.  Davidlohr agreed the 
> configuration was more complex but if you're going to go out and buy a 
> CHMU supported device then you can likely configure this correctly.

We (DAMON community) provide and support a auto-tuning based DAMON
configuration for general memory tiering on 2 nodes setup [1].  The support
means that if a user tried it and find it doesn't work as expected, they can
reach out to DAMON community for help.  In the case, we will help investigating
the issue and provide solutions.  We also merge back the solution to the
configuration and DAMON itself.

Of course our support is not constrained to only the auto-tuning based
configuration.  We samely help for any custom configuration usages.

Some people indeed trying the auto-tuning based config and reaching out to us
in the way.  We are helping them and improve DAMON.  I believe it will be
similar for CHMU case.

DAMON is an open source project that is actively maintained, supported and open
to changes.  Please feel free to ask questions and changes.

[1] https://github.com/damonitor/damo/blob/next/scripts/mem_tier.sh


Thanks,
SJ

[...]