From: Michal Hocko <mhocko@suse.com>
To: Guopeng Zhang <guopeng.zhang@linux.dev>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Muchun Song <muchun.song@linux.dev>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Guopeng Zhang <zhangguopeng@kylinos.cn>
Subject: Re: [PATCH] mm: memcg: stop reclaim when a limit update is superseded
Date: Mon, 27 Jul 2026 10:16:47 +0200 [thread overview]
Message-ID: <amcT75pLmA0hRUm1@tiehlicka> (raw)
In-Reply-To: <20260724021805.1234583-1-guopeng.zhang@linux.dev>
On Fri 24-07-26 10:18:05, Guopeng Zhang wrote:
> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
>
> kernfs serializes file operations only per open file, so separate open
> files can update the same memory.high or memory.max file concurrently.
> Both handlers store the new limit before synchronous reclaim, but
> continue to use the writer's local target in the reclaim loop. If another
> writer raises or removes the limit, the first writer can continue
> reclaiming toward a stale target.
>
> For memory.max, this can leave the writer looping indefinitely once
> reclaim retries are exhausted. The OOM path sees sufficient margin under
> the current limit and returns true without killing, while the writer
> still compares usage against its stale target and records another OOM
> event.
The current behavior is deliberate as described in b6e6edcfa4056.
What is an actual problem you are trying to fix?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2026-07-27 8:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 2:18 [PATCH] mm: memcg: stop reclaim when a limit update is superseded Guopeng Zhang
2026-07-24 3:32 ` Tao Cui
2026-07-24 6:53 ` Guopeng Zhang
2026-07-26 3:42 ` Andrew Morton
2026-07-26 5:57 ` Guopeng Zhang
2026-07-27 8:16 ` Michal Hocko [this message]
2026-07-27 12:59 ` Guopeng Zhang
2026-07-27 13:58 ` Michal Hocko
2026-07-29 6:15 ` Guopeng Zhang
2026-07-29 8:02 ` Michal Hocko
2026-07-29 19:11 ` Andrew Morton
2026-07-29 19:36 ` Johannes Weiner
2026-07-30 1:48 ` Guopeng Zhang
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=amcT75pLmA0hRUm1@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=guopeng.zhang@linux.dev \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=zhangguopeng@kylinos.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.