Re: [Linux Memory Hotness and Promotion] Notes from February 26, 2026

[Jonathan Cameron <jonathan.cameron@huawei.com>]

> ----->o-----  
> We touched on the CXL Hotness Monitoring Unit (CHMU) and whether any work 
> was on-going to abstract this in upstream Linux.  Both Google and Meta 
> were not actively looking at this.  Yiannis suggested Jonathan Cameron may 
> be looking at this for qemu and testing.  We concluded that not having 
> CHMU support upstream is not currently holding anything back and it might 
> be addressed in a year or so; it might also be solving a problem that 
> nobody has yet.

On this, sorry I didn't make the call.  Whilst we have some minimal support
in QEMU for emulating the CHMU to allow data capture, and a tracing style
kernel driver my priorities currently lie elsewhere. I might get back to
this a little later in the year. I'm aware that some others have been
experimenting further though but heard how they are getting on yet.

> ----->o-----  
> Yiannis brought up non-temporal stores for tiering and the possibility of 
> finding time to work on it in the next few weeks.  He saw great value in 
> this from the compression side and was trying to determine if this brings 
> value to CXL or tiered systems in general.  The idea is to extend 
> migrate_pages() for the demotion path so it uses non-temporal stores -- we 
> don't want to warm up our cache for cold memory.  Gregory noted that we 
> want to ensure that when allocating the folio as the migration target that 
> we would also need to make sure that's not in the cache for this cold 
> memory.  I noted that Shivank from AMD had previously presented to this 
> group about enlightening migrate_pages() for hardware assists and using 
> the "reason" field of migrate_pages() to differentiate different use 
> cases.

I'm also keen to see progress in this area.  There are lots of options
for bulk movement of data and tiering brings a specific set of constraints /
opportunities that perhaps don't apply so much elsewhere.

Jonathan