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

On Thu, 16 Jul 2026 12:55:55 -0400 Gregory Price <[email protected]> wrote:
> 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.

Hello Gregory, hello David,

So circling back here a little bit (sorry that it took a while to get back)

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

I think the confusion is that "toptier-ness" doesn't give the full picture
for whether a node is a promotion candidate, a promotion candidate node
needs to both be toptier (adistance < toptier_adistance) AND also have
CPUs. So a HBM node that is hotplugged can definitely be toptier
in that it has a smaller adistance than the toptier_adistance, and will
probably even have a smaller adistance than the DRAM node, but if it
doesn't have CPUs, it won't be a promotion candidate.

It gets a bit more confusing because this distinction is not a tier-wide
distinction; you can have two HBM nodes hotplugged where only one of them
is CPUless -- then we cannot make any statement on whether the tier is
a proper promotion candidate, only that one of the nodes within that
tier is a candidate.

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

The merits of calling a node a "toptier" node is therefore a little
dubious I think, it's just one part of whether a node can be promoted to.

Anyways, I think this is outside the scope of this series. I think that
for the scope of what I am working on I will try to move away from
referring to things as "toptier" nodes but rather call them 
"promotion candidate" nodes. I hope that distinction will make this
series easier to understand and read. 

> > > $ cat memory.tiered_max
> > > tier_0 20971520
> > > tier_1 31457280

One change here is that it is not really possible to have 0..N-1 indexed
tiers, since those are not stable. For instance, hotplugging a HBM
node (as David pointed out) would replace what tier_0 is. However,
one thing that remains stable is the abstract distance (adistance) the
tiers are associated with, so I'll preserve the ABI that I have right
now, so we can have something like

tier_42 20971520
tier_128 31457280

And if HBM does come up as the "highest tier" with the lowest abstract
distance we will just have

tier 16 1048576
tier_42 20971520
tier_128 31457280

And we will not have any problems with tier_0 defining DRAM and then
later switching to define HBM. It is certainly less interpretable but
I think this is the only way to have a stable set of tiers, since
adistance is pre-calculated for all possible nodes at lateinit time.

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

Thanks for your insights Gregory. All of what I am saying is just in
aggressive agreement with what you and David have pointed out.

I am working to make the next version generic across tiers.
Thank you both! I hope you all have a great weekend,
Joshua