Linux Documentation
 help / color / mirror / Atom feed
* [RFC 0/2] mm: add explicit goals to memcg memory.reclaim
@ 2026-09-04  6:51 Li Zhe
  2026-09-04  6:51 ` [RFC 1/2] mm: add goal=evict to memory.reclaim Li Zhe
  2026-09-04  6:51 ` [RFC 2/2] mm: add goal=demote " Li Zhe
  0 siblings, 2 replies; 3+ messages in thread
From: Li Zhe @ 2026-09-04  6:51 UTC (permalink / raw)
  To: akpm, david, ljs, liam, rppt, surenb, mhocko, tj, hannes,
	shakeel.butt, muchun.song, qi.zheng
  Cc: cgroups, linux-doc, linux-kernel, linux-mm, lizhe.67

memory.reclaim is used by userspace controllers as a proactive memcg
reclaim interface. On systems without memory tiering, a completed request
is normally interpreted as eviction-oriented progress: pages were freed
and the cgroup's charged footprint can drop.

Memory tiering makes that interpretation ambiguous. The reclaim scanner
may satisfy the requested amount by demoting cold folios from a faster
tier to a slower tier. That is useful aging behavior, but it means a
request can complete even though the cgroup's charged footprint is
unchanged. Userspace controllers that rely on memory.reclaim for actual
cgroup footprint reduction therefore lose the ability to request the same
kind of outcome they get on non-tiered systems.

At the same time, some controllers want the opposite operation: use the
reclaim scanner as a best-effort placement mechanism to move cold folios
from DRAM to CXL or other lower tiers, without evicting them from memory.
This can be used to maintain top-tier headroom or a desired
DRAM/CXL occupancy ratio according to workload policy.

This series keeps the existing behavior as the default, and adds explicit
opt-in goals for userspace controllers that want a more specific outcome
from memcg memory.reclaim:

  echo "1G goal=evict" > memory.reclaim

    Run the normal reclaim scanner and keep demotion enabled as part of
    tier aging, but do not count successful demotion toward completing the
    requested amount. This lets callers ask memory.reclaim to continue
    until eviction progress, rather than demotion-only progress, satisfies
    the request. If the cgroup has no usable demotion target, goal=evict
    falls back to the default goal=progress behavior.

  echo "1G goal=demote" > memory.reclaim

    Use the existing reclaim scanner for best-effort memory tier demotion
    without LRU folio eviction. This is intended for placement control,
    such as maintaining top-tier headroom or a desired DRAM/CXL occupancy
    ratio. Demoted folios remain charged to the cgroup, so this goal does
    not imply memory.current reduction. If the cgroup has no usable
    demotion target, the request fails early with -EAGAIN.

The default remains goal=progress, which is the current memory.reclaim
behavior. In that mode, the kernel's existing reclaim progress accounting
is unchanged and successful demotion can satisfy the requested amount.

Patch 1 preserves the tiered LRU aging model. It changes the completion
accounting for an eviction-oriented request, while still allowing demotion
to happen as an intermediate step. After enough demotion has been done in
a batch, reclaim avoids repeatedly scanning the top tiers in the cgroup's
allowed demotion hierarchy just to produce more demotion-only progress,
while still allowing lower tiers to age or reclaim normally.

Patch 2 constrains a request in the other direction: it allows best-effort
demotion as the requested action, while keeping folios that are not queued
for demotion instead of evicting them from the LRU. It also skips slab
shrinking, because slab reclaim cannot contribute demotion progress and
would otherwise be retried aggressively for an underfilled demotion
request.

This also keeps the ABI scoped to the existing memory.reclaim interface
instead of adding a new cgroup file. The goal key describes what kind of
progress the caller wants from the request; it does not select a source or
target tier, does not provide strict placement guarantees, and remains
subject to cgroup protection, swappiness balancing, reclaim eligibility,
and demotion target availability.

This series is memcg-only. The per-node reclaim interface shares the
parser but has different semantics: node reclaim can legitimately treat
demotion as the desired way to relieve pressure on a node. For that
reason, the new goals are rejected from the per-node path rather than
being given a different meaning there.

Li Zhe (2):
  mm: add goal=evict to memory.reclaim
  mm: add goal=demote to memory.reclaim

 Documentation/admin-guide/cgroup-v2.rst |  26 ++++
 include/linux/memory-tiers.h            |  13 ++
 mm/internal.h                           |   2 +
 mm/memory-tiers.c                       |  35 +++++-
 mm/vmscan.c                             | 154 ++++++++++++++++++++++--
 5 files changed, 219 insertions(+), 11 deletions(-)

-- 
2.20.1

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-09-04  6:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-04  6:51 [RFC 0/2] mm: add explicit goals to memcg memory.reclaim Li Zhe
2026-09-04  6:51 ` [RFC 1/2] mm: add goal=evict to memory.reclaim Li Zhe
2026-09-04  6:51 ` [RFC 2/2] mm: add goal=demote " Li Zhe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox