Re: [RFC PATCH 6/6] mm/memcontrol: Make memory.high tier-aware
From: Donet Tom
Date: Tue Mar 24 2026 - 11:58:56 EST
On 3/24/26 8:53 PM, Gregory Price wrote:
On Tue, Mar 24, 2026 at 04:21:06PM +0530, Donet Tom wrote:
IIUC The intent of this patch is to partition cgroup memory such thatThis is not accurate and an incorrect heuristic.
0 → toptier_high is backed by higher-tier memory, and
toptier_high → max is backed by lower-tier memory.
Based on this:
1.If top-tier usage exceeds toptier_high, pages should be
demoted to the lower tier.
2. If lower-tier usage exceeds (max - toptier_high), pages
should be swapped out.
Transiently, lower-tier usage may exceed (max - toptier_high) for any
number of reasons which should not be used as signal for pushing swap.
driving swap usage is a function of (usage > memory.high) without regard
for toptier / lowtier.
3. If total memory usage exceeds max, demotion should beThis is also incorrect, as it would drive agingin inversions.
avoided and reclaim should directly swap out pages.
Demotion is a natural extension of the LRU infrastructure:
toptier active -> toptier inactive -> lowtier inactive -> swap
if you do (toptier inactive -> swap) you have inverted the LRU.
Thanks, Gregory, for the clarification.
One remaining concern is that under cgroup memory pressure,
demotion to the lower tier can still happen. Since demotion
does not uncharge the memcg, this could still trigger OOM.
Is this an issue we should address?
As far as I know, from testing, we retain all the existing behavior - we
are just managing a limited resource (top tier memory) to manage the
noisy-neighbor issue. So...
Should we also handle cases (2) and (3) in this patch?No, I don't think we should
~Gregory