Hi Hui.
On Tue, Dec 30, 2025 at 11:01:58AM +0800, Hui Zhu hui.zhu@linux.dev wrote:
This allows administrators to suppress low-priority cgroups' memory usage based on custom policies implemented in BPF programs.
BTW memory.low was conceived as a work-conserving mechanism for prioritization of different workloads. Have you tried that? No need to go directly to (high) limits. (<- Main question, below are some secondary implementation questions/remarks.)
...
This series introduces a BPF hook that allows reporting additional "pages over high" for specific cgroups, effectively increasing memory pressure and throttling for lower-priority workloads when higher-priority cgroups need resources.
Have you considered hooking into calculate_high_delay() instead? (That function has undergone some evolution so it'd seem like the candidate for BPFication.)
...
- Cgroup hierarchy management (inheritance during online/offline)
I see you're copying the program upon memcg creation. Configuration copies aren't such a good way to properly handle hierarchical behavior. I wonder if this could follow the more generic pattern of how BPF progs are evaluated in hierarchies, see BPF_F_ALLOW_OVERRIDE and BPF_F_ALLOW_MULTI.
Example Results
...
Results show the low-priority cgroup (/sys/fs/cgroup/low) was significantly throttled:
- High-priority cgroup: 21,033,377 bogo ops at 347,825 ops/s
- Low-priority cgroup: 11,568 bogo ops at 177 ops/s
The stress-ng process in the low-priority cgroup experienced a ~99.9% slowdown in memory operations compared to the high-priority cgroup, demonstrating effective priority enforcement through BPF-controlled memory pressure.
As a demonstrator, it'd be good to compare this with a baseline without any extra progs, e.g. show that high-prio performed better and low-prio wasn't throttled for nothing.
Thanks, Michal