Message-ID: <6ff7dad904bcb27323ea21977e1160ebfa5e283d@linux.dev>
Date: Tue, 25 Nov 2025 12:39:11 +0000
From: hui.zhu@...ux.dev
To: "Michal Hocko" <mhocko@...e.com>
Cc: "Roman Gushchin" <roman.gushchin@...ux.dev>, "Andrew Morton"
 <akpm@...ux-foundation.org>, "Johannes Weiner" <hannes@...xchg.org>,
 "Shakeel Butt" <shakeel.butt@...ux.dev>, "Muchun Song"
 <muchun.song@...ux.dev>, "Alexei Starovoitov" <ast@...nel.org>, "Daniel
 Borkmann" <daniel@...earbox.net>, "Andrii Nakryiko" <andrii@...nel.org>,
 "Martin KaFai Lau" <martin.lau@...ux.dev>, "Eduard Zingerman"
 <eddyz87@...il.com>, "Song Liu" <song@...nel.org>, "Yonghong Song"
 <yonghong.song@...ux.dev>, "John Fastabend" <john.fastabend@...il.com>,
 "KP Singh" <kpsingh@...nel.org>, "Stanislav Fomichev" <sdf@...ichev.me>,
 "Hao Luo" <haoluo@...gle.com>, "Jiri Olsa" <jolsa@...nel.org>, "Shuah
 Khan" <shuah@...nel.org>, "Peter Zijlstra" <peterz@...radead.org>,
 "Miguel Ojeda" <ojeda@...nel.org>, "Nathan Chancellor"
 <nathan@...nel.org>, "Kees Cook" <kees@...nel.org>, "Tejun Heo"
 <tj@...nel.org>, "Jeff Xu" <jeffxu@...omium.org>, mkoutny@...e.com, "Jan
 Hendrik Farr" <kernel@...rr.cc>, "Christian Brauner"
 <brauner@...nel.org>, "Randy Dunlap" <rdunlap@...radead.org>, "Brian
 Gerst" <brgerst@...il.com>, "Masahiro Yamada" <masahiroy@...nel.org>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 cgroups@...r.kernel.org, bpf@...r.kernel.org,
 linux-kselftest@...r.kernel.org, "Hui Zhu" <zhuhui@...inos.cn>
Subject: Re: [RFC PATCH 0/3] Memory Controller eBPF support

2025年11月25日 20:12, "Michal Hocko" <mhocko@...e.com mailto:mhocko@...e.com?to=%22Michal%20Hocko%22%20%3Cmhocko%40suse.com%3E > 写到:


> 
> On Fri 21-11-25 02:46:31, hui.zhu@...ux.dev wrote:
> 
> > 
> > 2025年11月21日 03:20, "Michal Hocko" <mhocko@...e.com mailto:mhocko@...e.com?to=%22Michal%20Hocko%22%20%3Cmhocko%40suse.com%3E > 写到:
> >  
> >  
> >  
> >  On Thu 20-11-25 09:29:52, hui.zhu@...ux.dev wrote:
> >  [...]
> >  
> >  > 
> >  > I generally agree with an idea to use BPF for various memcg-related
> >  > policies, but I'm not sure how specific callbacks can be used in
> >  > practice.
> >  > 
> >  > Hi Roman,
> >  > 
> >  > Following are some ideas that can use ebpf memcg:
> >  > 
> >  > Priority‑Based Reclaim and Limits in Multi‑Tenant Environments:
> >  > On a single machine with multiple tenants / namespaces / containers,
> >  > under memory pressure it’s hard to decide “who should be squeezed first”
> >  > with static policies baked into the kernel.
> >  > Assign a BPF profile to each tenant’s memcg:
> >  > Under high global pressure, BPF can decide:
> >  > Which memcgs’ memory.high should be raised (delaying reclaim),
> >  > Which memcgs should be scanned and reclaimed more aggressively.
> >  > 
> >  > Online Profiling / Diagnosing Memory Hotspots:
> >  > A cgroup’s memory keeps growing, but without patching the kernel it’s
> >  > difficult to obtain fine‑grained information.
> >  > Attach BPF to the memcg charge/uncharge path:
> >  > Record large allocations (greater than N KB) with call stacks and
> >  > owning file/module, and send them to user space via a BPF ring buffer.
> >  > Based on sampled data, generate:
> >  > “Top N memory allocation stacks in this container over the last 10 minutes,”
> >  > Reports of which objects / call paths are growing fastest.
> >  > This makes it possible to pinpoint the root cause of host memory
> >  > anomalies without changing application code, which is very useful
> >  > in operations/ops scenarios.
> >  > 
> >  > SLO‑Driven Auto Throttling / Scale‑In/Out Signals:
> >  > Use eBPF to observe memory usage slope, frequent reclaim,
> >  > or near‑OOM behavior within a memcg.
> >  > When it decides “OOM is imminent,” instead of just killing/raising
> >  > limits, it can emit a signal to a control‑plane component.
> >  > For example, send an event to a user‑space agent to trigger
> >  > automatic scaling, QPS adjustment, or throttling.
> >  > 
> >  > Prevent a cgroup from launching a large‑scale fork+malloc attack:
> >  > BPF checks per‑uid or per‑cgroup allocation behavior over the
> >  > last few seconds during memcg charge.
> >  > 
> >  AFAIU, these are just very high level ideas rather than anything you are
> >  trying to target with this patch series, right?
> >  
> >  All I can see is that you add a reclaim hook but it is not really clear
> >  to me how feasible it is to actually implement a real memory reclaim
> >  strategy this way.
> >  
> >  In prinicipal I am not really opposed but the memory reclaim process is
> >  rather involved process and I would really like to see there is
> >  something real to be done without exporting all the MM code to BPF for
> >  any practical use. Is there any POC out there?
> >  
> >  Hi Michal,
> >  
> >  I apologize for not delivering a more substantial POC.
> >  
> >  I was hesitant to add extensive eBPF support to memcg
> >  because I wasn't certain it aligned with the community's
> >  vision—and such support would require introducing many
> >  eBPF hooks into memcg.
> >  
> >  I will add more eBPF hook to memcg and provide a more
> >  meaningful POC in the next version.
> > 
> Just to make sure we are on the same page. I am not suggesting we need
> more of those hooks. I just want to see how many do we really need in
> order to have a sensible eBPF driven reclaim policy which seems to be
> the main usecase you want to puruse, right?

I got your point.

My goal is implement dynamic memory reclamation for memcgs without limits,
triggered by specific conditions.

For instance, with memcg A and memcg B both unlimited, when memcg A faces
high PSI pressure, ebpf control memcg B do some memory reclaim work when
it try charge.

Best,
Hui

> -- 
> Michal Hocko
> SUSE Labs
>

Powered by blists - more mailing lists