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

[Shakeel Butt <shakeel.butt@linux.dev>]

On Wed, Sep 30, 2026 at 01:35:33PM -1000, Tejun Heo wrote:
> 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?

mlock(), madvise(POPULATE), fadvise(WILLNEED) are the obvious ones where large
amount of memory can be allocated before returning to userspace. Now regarding
the in-kernel sync high enforcement for these cases helps or not, I think it
depends on what the user is trying to achieve with memory.high. One scenario I
can think of is an overcommitted system where admin dynamically adjusts
memory.high limits of colocated workloads based on their working set size. The
memory spikes will be smoothen by memory.high otherwise colocated workload can
be negatively impact. In this example, ineffective memory.high will not be able
to avoid global pressure which can impact colocated workloads.

BTW the above scenario is just an example and not something I am proposing.
Actually I think memory overcommit in the presense sync throttling can
potentially cause more isolation issues.

> 
> > 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.

What is "This" in the above statement?

> 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.

Here if you meant that default behavior of memory.high should work for most (if
not all) users then we are on same page. If some user want memory.high reclaim
to happen in a separate thread instead of return-to-userspace or synchronously,
this proposal provides mechanism through BPF to such users to achieve their
goals.