From: Donet Tom <donettom@linux.ibm.com>
To: Gregory Price <gourry@gourry.net>
Cc: Joshua Hahn <joshua.hahnjy@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [RFC PATCH 6/6] mm/memcontrol: Make memory.high tier-aware
Date: Tue, 24 Mar 2026 21:16:59 +0530 [thread overview]
Message-ID: <5bf5a4f2-0505-44ef-9cea-df6ec25d9603@linux.ibm.com> (raw)
In-Reply-To: <acKsb06lnywch8DV@gourry-fedora-PF4VCD3F>
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 that
>> 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.
>>
> This is not accurate and an incorrect heuristic.
>
> 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 be
>> avoided and reclaim should directly swap out pages.
>>
> This is also incorrect, as it would drive agingin inversions.
> 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
>
next prev parent reply other threads:[~2026-03-24 15:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 22:38 [RFC PATCH 0/6] mm/memcontrol: Make memcg limits tier-aware Joshua Hahn
2026-02-23 22:38 ` [RFC PATCH 1/6] mm/memory-tiers: Introduce tier-aware memcg limit sysfs Joshua Hahn
2026-02-23 22:38 ` [RFC PATCH 2/6] mm/page_counter: Introduce tiered memory awareness to page_counter Joshua Hahn
2026-02-23 22:38 ` [RFC PATCH 3/6] mm/memory-tiers, memcontrol: Introduce toptier capacity updates Joshua Hahn
2026-02-23 22:38 ` [RFC PATCH 4/6] mm/memcontrol: Charge and uncharge from toptier Joshua Hahn
2026-02-23 22:38 ` [RFC PATCH 5/6] mm/memcontrol, page_counter: Make memory.low tier-aware Joshua Hahn
2026-02-23 22:38 ` [RFC PATCH 6/6] mm/memcontrol: Make memory.high tier-aware Joshua Hahn
2026-03-11 22:05 ` Bing Jiao
2026-03-12 19:44 ` Joshua Hahn
2026-03-24 10:51 ` Donet Tom
2026-03-24 15:23 ` Gregory Price
2026-03-24 15:46 ` Donet Tom [this message]
2026-03-24 15:44 ` Joshua Hahn
2026-03-24 16:06 ` Donet Tom
2026-02-24 11:27 ` [RFC PATCH 0/6] mm/memcontrol: Make memcg limits tier-aware Michal Hocko
2026-02-24 16:13 ` Joshua Hahn
2026-02-24 18:49 ` Gregory Price
2026-02-24 20:03 ` Kaiyang Zhao
2026-02-26 8:04 ` Michal Hocko
2026-02-26 16:08 ` Joshua Hahn
2026-03-24 10:30 ` Donet Tom
2026-03-24 14:58 ` Joshua Hahn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5bf5a4f2-0505-44ef-9cea-df6ec25d9603@linux.ibm.com \
--to=donettom@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=cgroups@vger.kernel.org \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox