Re: [PATCH] mm/mglru: fix cgroup OOM during MGLRU state switching

[Barry Song <21cnbao@gmail.com>]

On Mon, Mar 2, 2026 at 4:14 PM Yafang Shao <laoar.shao@gmail.com> wrote:
[...]
> > > > If we want a per-workload LRU, this could be a good
> > > > place for eBPF to hook into folio enqueue, dequeue,
> > > > and scanning. There is a project related to this [1][2].
> > > >
> > > > // Policy function hooks
> > > > struct cache_ext_ops {
> > > >        s32 (*policy_init)(struct mem_cgroup *memcg);
> > > >        // Propose folios to evict
> > > >        void (*evict_folios)(struct eviction_ctx *ctx,
> > > >                  struct mem_cgroup *memcg);
> > > >        void (*folio_added)(struct folio *folio);
> > > >        void (*folio_accessed)(struct folio *folio);
> > > >        // Folio was removed: clean up metadata
> > > >        void (*folio_removed)(struct folio *folio);
> > > >        char name[CACHE_EXT_OPS_NAME_LEN];
> > > > };
> > > >
> > > > However, we would need a very strong and convincing
> > > > user case to justify it.
> > >
> > > Thanks for the info.
> > > We're actually already running a BPF-based reclaimer in production,
> > > but we don't have immediate plans to upstream or propose it just yet.
> >
> > I know you are always far ahead of everyone else. I’m looking forward
> > to seeing your code and use cases when you are ready.
>
> Don't say it that way, that is not cooperative.
> We've only deployed a limited BPF-based memcg async reclaimer
> internally, and it is currently scoped to our own workloads.
>

Don’t be so sensitive:-) When I say you are far ahead, that’s exactly
what I mean. I truly admire your work on making LRU programmable.
That’s all.

I understand that you have only deployed a limited BPF-based case,
so you need more time before sharing it. I am not criticizing you for
not sharing it yet. Please don’t misunderstand me.

Best Regards
Barry