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

[Matthew Wilcox <willy@infradead.org>]

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 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.

I particularly don't see a case for trying to do it on single-page
granularity.  There's just too much damn information to track.  Maybe at
a 2MB or 1GB boundary, but not per page.