From: Tejun Heo <tj@kernel.org>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alexei Starovoitov <ast@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
JP Kobryn <jp.kobryn@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Michal Koutny <mkoutny@suse.com>,
Amery Hung <ameryhung@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Emil Tsalapatis <emil@etsalapatis.com>,
Jiri Olsa <jolsa@kernel.org>,
Ihor Solodrai <ihor.solodrai@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
Jiayuan Chen <jiayuan.chen@linux.dev>,
hui.zhu@linux.dev, Donet Tom <donettom@linux.ibm.com>,
Greg Thelen <gthelen@google.com>,
Meta kernel team <kernel-team@meta.com>,
linux-mm@kvack.org, bpf@vger.kernel.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] memcg_ext: memcg policy through cgroup-attached struct_ops
Date: Fri, 02 Oct 2026 06:25:08 -1000 [thread overview]
Message-ID: <c1fdbe4f99352a102b38c7d131215d5a@kernel.org> (raw)
In-Reply-To: <ar7H__jzvWVtqSn5@linux.dev>
Hello, Shakeel.
On Thu, Oct 01, 2026 at 03:56:47PM -0700, Shakeel Butt wrote:
> We are in agreement on (1) and (2) completely. For (3), I am fine with removing
> the sync enforcement, but for throttling points for bulk operation sites,
> I think we should only add them when there is an actual use case for that
> or someone complains about overrun from those sites.
On (3), if removing synchronous enforcement wouldn't regress anything,
that's fine, but why was it added in the first place?
> Now, setting aside the default behavior of memory.high, I want to provide
> additional flexibility to users for (3) specifically. One specific case is
> letting users opt in to async reclaim instead of the other forms of memory.high
> enforcement. Basically, users can specify that instead of having their
> application threads throttled, they would prefer async reclaim to bring their
> usage back below memory.high.
As for flexibility, we already have a gradient of enforcement around
memory.high. Is the need here to make the shape of that gradient
configurable? Can you give specific examples where this is needed?
Thanks.
--
tejun
next prev parent reply other threads:[~2026-10-02 16:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 19:25 [RFC PATCH 0/4] memcg_ext: memcg policy through cgroup-attached struct_ops Shakeel Butt
2026-09-21 19:25 ` [RFC PATCH 1/4] bpf, cgroup: fix cgroup struct_ops query for a second attach type Shakeel Butt
2026-09-21 20:19 ` bot+bpf-ci
2026-09-29 11:49 ` Yafang Shao
2026-09-21 19:25 ` [RFC PATCH 2/4] memcg_ext: add cgroup-attached bpf_memcg_ops Shakeel Butt
2026-09-21 19:41 ` sashiko-bot
2026-09-21 19:25 ` [RFC PATCH 3/4] memcg_ext: allow BPF to defer memory.high enforcement Shakeel Butt
2026-09-24 20:14 ` JP Kobryn
2026-09-24 21:19 ` Shakeel Butt
2026-09-21 19:25 ` [RFC PATCH 4/4] selftests/bpf: add a cgroupfs lock-holder bpf_memcg_ops sample Shakeel Butt
2026-09-23 13:07 ` [RFC PATCH 0/4] memcg_ext: memcg policy through cgroup-attached struct_ops Yafang Shao
2026-09-23 15:47 ` Shakeel Butt
2026-09-24 10:01 ` Yafang Shao
2026-09-24 20:42 ` Shakeel Butt
2026-09-28 3:23 ` Yafang Shao
2026-09-28 20:40 ` Tejun Heo
2026-09-30 13:28 ` Shakeel Butt
2026-09-30 23:35 ` Tejun Heo
2026-10-01 1:00 ` Shakeel Butt
2026-10-01 18:42 ` Tejun Heo
2026-10-01 22:56 ` Shakeel Butt
2026-10-02 16:25 ` Tejun Heo [this message]
2026-10-02 22:19 ` Shakeel Butt
2026-10-03 7:17 ` Tejun Heo
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=c1fdbe4f99352a102b38c7d131215d5a@kernel.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=donettom@linux.ibm.com \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=hui.zhu@linux.dev \
--cc=ihor.solodrai@linux.dev \
--cc=jiayuan.chen@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=jp.kobryn@linux.dev \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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.