2025年11月25日 20:12, "Michal Hocko" <[email protected] mailto:[email protected]?to=%22Michal%20Hocko%22%20%3Cmhocko%40suse.com%3E > 写到:
> > On Fri 21-11-25 02:46:31, [email protected] wrote: > > > > > 2025年11月21日 03:20, "Michal Hocko" <[email protected] > > mailto:[email protected]?to=%22Michal%20Hocko%22%20%3Cmhocko%40suse.com%3E > > > 写到: > > > > > > > > On Thu 20-11-25 09:29:52, [email protected] 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 >
