Re: [RFC PATCH 0/4] memcg_ext: memcg policy through cgroup-attached struct_ops

[Tejun Heo]

Hello, Shakeel.

On Mon, Sep 21, 2026 at 12:25:55PM -0700, Shakeel Butt wrote:
> try_charge_memcg() calls __mem_cgroup_handle_over_high() before it returns,
> which reclaims and can throttle the task.  That happens wherever the charge
> happens, so a task holding a kernel lock can be stuck there, and everything
> waiting on that lock is stuck behind it.

Why not just raise the lazy bound high enough that most charges never
enforce inline, and maybe annotate the specific paths that can allocate a
lot so that they do? Inline enforcement should be the exception, not the
rule. Flipping that and then trying to reverse it with custom BPF policies
doesn't make a lot of sense.

> One concrete scenario which can be resolved by this new feature is the
> kernfs notify worker. It delivers notifications with the cgroup2
> kernfs_rwsem held for read, and the charge for the delivery allocation goes
> to the cgroup that set the watch, usually one already under pressure. So
> the worker reclaims while holding the lock, a waiting writer blocks every
> later reader, and anything touching cgroupfs stalls for seconds.

Slowing down the kworker inline doesn't make sense. It's charging on behalf
of the watcher through set_active_memcg(), which already tells us whose debt
it is. Wouldn't it make more sense to defer the debt to that cgroup instead
of slowing down the kernel thread?

Thanks.

--
tejun