Re: [RFC PATCH 0/9 v2] mm/memcontrol: Make memory cgroup limits tier-aware

[Gregory Price]

On Thu, Jul 16, 2026 at 03:11:30PM +0200, David Hildenbrand (Arm) wrote:
> > 
> > First, for the multi-numa-per-tier case, I think this is already pretty well
> > handled by my series. Once we realize that a memcg is consuming too much memory
> > from a tier, we trigger reclaim from that memcg via
> > try_to_free_mem_cgroup_pages,
> > which as far as I can tell already handles the multi-numa per memcg case.
> > Other than restricting the scan_control's nodemask to target the nodes
> > from that tier, I don't think there's anything else to be done.
> 
> I am not really sure about the "toptier" notion, in particular if your memory
> hierarchy is not static.
> 
> Imagine that you have only DRAM in your system. Then you hotplug some slow CXL
> memory. The you hotplug some HBM CXL memory.
> 
> The meanting of "toptier" changes, which is rather confusing to me.
> 

I think this is a naming problem.

Maybe we should start calling this "initiator tier" or something.
Maybe tier is even the wrong notion here, but it's the best we have.

But I agree "toptier" naming doesn't generalize to complex systems.

> > 
> > $ cat memory.tiered_max
> > tier_0 20971520
> > tier_1 31457280
> > ...
> 
> memcgs are currently not NUMA aware, so this could be one possible direction.
> 
> But is "tier" the right abstraction? I really don't know.
>

Really I think we're trying to classify 3 general pools of memory

- Precious:      HBM
- Preferred:     DRAM  (initiator preferred targets)
- Non-Preferred: CXL   (fallback and demotion targets)

HBM nodes are already weird in terms of fallback ordering, but ignoring
that for a moment.

Non-preferred "tiers" are slightly different than preferred "tiers".

Under normal operation (assume no mempolicy or cgroup weirdness):

1) Direct reclaim NEVER targets non-preferred tiers (kswapd only)
2) Promotion NEVER targets non-preferred tiers (promotion -> toptier)
3) Under total system pressure (direct reclaim on top tier), we swap
   directly from the preferred tier out to swap

So non-preferred tiers don't have the same reclaim behavior associated
with them.  In fact i'm pretty sure we could summarize non-preferred
tiers as being managed hyper-lazily in the current scheme.

(if there's space, have at it - otherwise you have to wait for kswapd).

In my head, I think what we mostly want is:
  - Precious      - controlled entry,  Private node?
  - Preferred     - semi-precious, fairness desired
  - Non-preferred - not precious, lazy managed, no fairness

Just some food for thought.  I've been poking at making non-preferred
tiers less lazily managed, and I'm just finding this results to massive
regressions.

~Gregory