From: Shakeel Butt <shakeel.butt@linux.dev>
To: JP Kobryn <jp.kobryn@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>,
Muchun Song <muchun.song@linux.dev>, Tejun Heo <tj@kernel.org>,
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 3/4] memcg_ext: allow BPF to defer memory.high enforcement
Date: Thu, 24 Sep 2026 14:19:04 -0700 [thread overview]
Message-ID: <arWTPMEm5C9tFeGc@linux.dev> (raw)
In-Reply-To: <c8b8504c-8e54-479f-a372-3d2755edaf88@linux.dev>
On Thu, Sep 24, 2026 at 01:14:59PM -0700, JP Kobryn wrote:
[...]
> > +static void bpf_memcg_ctx_init(struct bpf_memcg_ctx *ctx,
> > + struct mem_cgroup *memcg,
> > + struct mem_cgroup *over_limit, gfp_t gfp_mask)
> > +{
> > + ctx->memcg = memcg;
> > + ctx->memcg_over_limit = over_limit;
> > + ctx->task = current;
> > + ctx->cgroup_id = cgroup_id(memcg->css.cgroup);
> > + ctx->over_limit_cgroup_id = over_limit ?
> > + cgroup_id(over_limit->css.cgroup) : 0;
> > + ctx->nr_pages_over_high = current->memcg_nr_pages_over_high;
> > + ctx->gfp_flags = (__force u32)gfp_mask;
> > +}
> > +
> > +u32 bpf_memcg_high_policy(struct mem_cgroup *memcg,
> > + struct mem_cgroup *over_limit, gfp_t gfp_mask)
> > +{
> > + const struct bpf_prog_array_item *item;
> > + const struct bpf_memcg_ops *ops;
> > + struct bpf_memcg_ctx ctx;
> > + u32 acc = BPF_MEMCG_HIGH_NO_OPINION;
> > + struct cgroup *cgrp;
> > +
> > + if (!cgroup_bpf_enabled(CGROUP_MEMCG_OPS))
> > + return acc;
> > +
> > + /*
> > + * Only the default hierarchy has a cgroup_bpf, and the static key is
> > + * global, so one policy anywhere turns this on for v1 memcgs too. A
> > + * v1 memcg still cannot get here, because memory.high and swap.high
> > + * are both v2-only and so it never builds the debt that leads to this
> > + * call. A hook on a path v1 can reach needs its own cgroup_on_dfl()
> > + * test: a v1 cgroup has no effective array and an uninitialised
> > + * cgrp->bpf.refcnt.
> > + */
> > + cgrp = memcg->css.cgroup;
> > +
> > + /*
> > + * A program can allocate and re-enter the charge path. Skip the
> > + * nested call. This guards the callbacks only.
> > + */
> > + if (current->in_bpf_memcg)
> > + return acc;
> > + current->in_bpf_memcg = 1;
> > +
> > + rcu_read_lock_dont_migrate();
> > +
> > + /*
> > + * A memcg outlives its cgroup while it has charges, and
> > + * cgroup_bpf_release() frees the arrays when the cgroup goes.
> > + */
> > + if (!cgroup_bpf_tryget_live(cgrp))
> > + goto out;
> > +
> > + bpf_memcg_ctx_init(&ctx, memcg, over_limit, gfp_mask);
> > +
> > + bpf_cgroup_struct_ops_foreach(ops, item, cgrp, CGROUP_MEMCG_OPS) {
> > + if (ops->high_policy)
> > + acc |= ops->high_policy(&ctx) &
> > + BPF_MEMCG_HIGH_VALID_MASK;
> > + }
>
> If I'm reading correctly, the gfp_mask at this point doesn't account for
> task restrictions, so the BPF program may see __GFP_FS, __GFP_IO, etc
> which may later be cleared when setting up the scan_control instance.
I am passing the same gfp_mask which has been passed to try_charge_memcg(), so
it should be same as what reclaim_high (reclaim internal) sees.
next prev parent reply other threads:[~2026-09-24 21:19 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 [this message]
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
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=arWTPMEm5C9tFeGc@linux.dev \
--to=shakeel.butt@linux.dev \
--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=song@kernel.org \
--cc=tj@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.