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

[Yongting Lin]

On Mon, Aug 10, 2026 at 05:16:39AM +0100, Matthew Wilcox wrote:
> On Mon, Aug 10, 2026 at 11:38:14AM +0800, Yongting Lin wrote:
> > On Tue, Jul 28, 2026 at 07:24:46PM +0100, Matthew Wilcox wrote:
> > > I don't think we should do this. I don't think it's a use-case that
> > > customers actually want; I think it's something CPU vendors think their
> > > customers want. I've said this repeatedly over the months this patchset
> > > has been in development. I say no.
> >
> > From our perspective, this is not merely a hypothetical use case. We
> > are actively developing and evaluating CXL tiered-memory systems, and
> > expect promoting CXL-resident pages that become hot back to DRAM to be
> > a practical requirement.
>
> But what *is* your use case?  Truly hot data ends up in L1/L2/L3 no
> matter whether it came across the ridiculously high latency CXL link or
> from regular DRAM.  So we're talking about "warm" data that's presumably
> measured in gigabytes (since current server CPUs have about half a
> gigabyte of LLC)

I think some context may have been lost in my wording. Ignoring CPU
caches for the moment, my original point was that the hot portion of a
workload should reside in DRAM, while its cold portion can be placed on
CXL. If some CXL-resident memory later becomes frequently accessed, it
becomes hot from this placement perspective and should be considered
for promotion back to DRAM.

In the terminology of your cache-related distinction, what I called
"hot" memory here would more accurately be called "warm" memory.

Although LLCs have become fairly large, for the working set that does
not fit in the LLC, placing it in DRAM rather than CXL still makes a
clear performance difference, at least for the workloads we have
evaluated.

> I see the basis for saying "this task is low priority, it gets its memory
> allocated on CXL" and "this task is high priority, it gets its memory
> allocated on DRAM".  I don't see the use case where we're trying to figure
> out that region A of this task is sufficiently warmer than region B, and so
> we want to demote region B back to CXL and promote region A back to DRAM.

Our motivation for using CXL is not related to task priority. Many of
our services have clearly distinguishable warm and cold memory within
the same workload, and we would like to demote the cold portion to CXL.

Although these workloads usually exhibit access locality, their access
patterns can also change abruptly: memory that was cold and demoted to
CXL can become actively accessed again. In that case, we may need to
promote it back to DRAM. A mechanism that can identify such changes
accurately and promptly would allow those pages to be moved back to
DRAM sooner and reduce the resulting performance loss.

Thanks,
Yongting