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

[Tejun Heo <tj@kernel.org>]

Hello, Shakeel.

On Wed, Sep 30, 2026 at 06:28:21AM -0700, Shakeel Butt wrote:
> I am fine with changing the default behavior. Actually, I have been
> contemplating whether I should propose a revert of commit c9afe31ec443e
> ("memcg: synchronously enforce memory.high for large overcharges") because
> it has introduced more problems than it has solved, but that is a separate
> topic. The initial commit already mentioned that MEMCG_CHARGE_BATCH was used
> arbitrarily, so replacing it with something big might be acceptable. I want
> to keep that decision separate.

Which kernel paths allocate enough for this to matter? Can you give specific
examples where the in-kernel synchronous enforcement helps?

> Returning to the actual proposal, my plan was to start small with a narrow,
> specific use case. However, my long-term plan is to provide a mechanism to
> change the default behavior for custom use cases. For example, for
> memory.high, I will provide a way for users to specify what behavior they
> want, i.e., whether or not they want more synchronous throttling.

This doesn't seem like a policy problem. It feels like a problem that should
be and can reasonably be solved for everybody, so I'm not sure whether BPF is
the right call for this specific purpose.

Thanks.

--
tejun