Re: [RFC PATCH v3 0/3] mm: use non-temporal stores for demotion

[Huan Nguyen <nhuhuan@google.com>]

On Tue, Nov 3, 2026 at 4:09 PM Zi Yan <ziy@nvidia.com> wrote:
>
> On 3 Nov 2026, at 17:30, Huan Nguyen wrote:
>
> > This series continues the non-temporal demotion work originally posted
> > by Yiannis Nikolakopoulos [1].
> >
> > Motivation
> > ==========
> > Memory tier demotion moves cold folios from local DRAM to slower memory
> > tiers, such as CXL or remote NUMA nodes. Standard store instructions
> > force the CPU to allocate cache lines for cold data that is unlikely to
> > be referenced in the near term.
> >
> > Using non-temporal stores and prefetching on x86 bypasses CPU cache
> > allocation, protecting active workload working sets and improving
> > demotion throughput.
> >
> > Changes in v3
> > =============
> > - Unified MCE-safe NT copy (addressing v2 Open #1):
> >   Implement copy_mc_page_nt() in x86 assembly to provide machine-check
> >   safe copying using non-temporal stores (movnti) and prefetchnta.
> >
> > - Architecture abstraction (addressing v2 Open #2):
> >   v2 relied on memcpy_flushcache(), which lacks non-temporal stores on
> >   architectures like arm64. RFC v3 replaces this with a dedicated
> >   __HAVE_ARCH_COPY_PAGE_NT interface and generic fallback, enabling
> >   architectures to plug in native non-temporal routines independently.
> >
> > - Memory ordering:
> >   Add a wmb() barrier at the end of folio_mc_copy_nt() to ensure weakly
> >   ordered non-temporal stores are drained before page tables are updated.
> >
> > Discussions
> > ===========
> > 1. Migration mode vs. migration control refactoring:
> >    Currently, this series introduces MIGRATE_ASYNC_NONTEMPORAL into
> >    enum migrate_mode. In parallel, Shivank Garg's migration refactoring
> >    series [2] consolidates migration arguments into migrate_control.
> >    Once that lands, demotion can simply rely on the migration reason
> >    instead of adding a dedicated migration mode and helper.
>
> If that is the ultimate goal, why not do it in this series to avoid
> code churn? You probably can coordinate with Shivank on how to move
> the migration control refactoring code to this series.

Thanks for the suggestion. I reached out to Shivank and we are
coordinating on this.

Best,
Huan