Hi Hui. On Tue, Dec 30, 2025 at 11:01:58AM +0800, Hui Zhu <[email protected]> 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.) ... > 3. 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
signature.asc
Description: PGP signature
