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

[Tejun Heo]

Hello,

On Fri, Oct 02, 2026 at 03:19:38PM -0700, Shakeel Butt wrote:
> > On (3), if removing synchronous enforcement wouldn't regress anything,
> > that's fine, but why was it added in the first place?
> > 
> 
> I added the sync enforcement to replace a Google internal feature which, on
> memcg OOM, allows node controller couple of seconds to either increase the max
> limit or let the memcg die. With sync enforcement, memory.high helped in simple
> benchmarks. However later testing on some realistic Google workloads, I found
> out that several thousand threads are very normal of typical Google workload and
> memory.high sync enforcement is not effective on applications with large amount
> of threads. In addition, there were workloads which on noticing blocked threads,
> keep forking more threads. At the end implementing that feature using
> memory.high didn't pan out.

Yeah, if there's no known active usecases, might as well start by dropping
it and see whether anyone complains.

> > 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?
> 
> The concrete example I have is the kswapd like async reclaimers (plural) per
> memcg. Kswapd is woken up on free pages falling below low watermark and then
> when free pages fall below min watermark, allocators get throttled (enter direct
> reclaim). I want to apply similar concept to memcg (but with right cpu
> accounting and more concurrency). 

I see. Yeah, ISTR talking about async reclaim for memory.high. I don't know
much about mm but that makes sense to me and I'm not against allowing
customization of memory.high behavior via BPF; however, most use cases can
likely be served with a reasonably designed dumb interface and that likely
is a better place to start.

Thanks.

-- 
tejun