2025年12月30日 17:49, "Michal Koutný" <[email protected] mailto:[email protected]?to=%22Michal%20Koutn%C3%BD%22%20%3Cmkoutny%40suse.com%3E > 写到:
Hi Michal and Ridong, > > 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.) > > ... > memory.low is a helpful feature, but it can struggle to effectively throttle low-priority processes that continuously access their memory. For instance, consider the following example I ran: root@ubuntu:~# echo $((4 * 1024 * 1024 * 1024)) > /sys/fs/cgroup/high/memory.low root@ubuntu:~# cgexec -g memory:low stress-ng --vm 4 --vm-keep --vm-bytes 80% --vm-method all --seed 2025 --metrics -t 60 & cgexec -g memory:high stress-ng --vm 4 --vm-keep --vm-bytes 80% --vm-method all --seed 2025 --metrics -t 60 [1] 2011 stress-ng: info: [2011] setting to a 1 min, 0 secs run per stressor stress-ng: info: [2012] setting to a 1 min, 0 secs run per stressor stress-ng: info: [2011] dispatching hogs: 4 vm stress-ng: info: [2012] dispatching hogs: 4 vm stress-ng: metrc: [2012] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s CPU used per RSS Max stress-ng: metrc: [2012] (secs) (secs) (secs) (real time) (usr+sys time) instance (%) (KB) stress-ng: metrc: [2012] vm 23584 60.21 2.75 15.94 391.73 1262.07 7.76 649988 stress-ng: info: [2012] skipped: 0 stress-ng: info: [2012] passed: 4: vm (4) stress-ng: info: [2012] failed: 0 stress-ng: info: [2012] metrics untrustworthy: 0 stress-ng: info: [2012] successful run completed in 1 min, 0.22 secs stress-ng: metrc: [2011] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s CPU used per RSS Max stress-ng: metrc: [2011] (secs) (secs) (secs) (real time) (usr+sys time) instance (%) (KB) stress-ng: metrc: [2011] vm 23584 60.22 3.06 16.19 391.63 1224.97 7.99 688836 stress-ng: info: [2011] skipped: 0 stress-ng: info: [2011] passed: 4: vm (4) stress-ng: info: [2011] failed: 0 stress-ng: info: [2011] metrics untrustworthy: 0 stress-ng: info: [2011] successful run completed in 1 min, 0.23 secs As the results show, setting memory.low on the cgroup with the high-priority workload did not improve its memory performance. However, memory.low is beneficial in many other scenarios. Perhaps extending it with eBPF support could help address a wider range of issues. > > > > 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.) > It seems that try_charge_memcg will not reach __mem_cgroup_handle_over_high if it only hook calculate_high_delay without setting memory.high. What do you think about hooking try_charge_memcg as well, so that it ensures __mem_cgroup_handle_over_high is called? > ... > > > > > 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. I will support them in the next version. > > > > > 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 for your remind. This is a test log in the test environment without any extra progs: root@ubuntu:~# cgexec -g memory:low stress-ng --vm 4 --vm-keep --vm-bytes 80% \ --vm-method all --seed 2025 --metrics -t 60 \ & cgexec -g memory:high stress-ng --vm 4 --vm-keep --vm-bytes 80% \ --vm-method all --seed 2025 --metrics -t 60 [1] 982 stress-ng: info: [982] setting to a 1 min, 0 secs run per stressor stress-ng: info: [983] setting to a 1 min, 0 secs run per stressor stress-ng: info: [982] dispatching hogs: 4 vm stress-ng: info: [983] dispatching hogs: 4 vm stress-ng: metrc: [982] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s CPU used per RSS Max stress-ng: metrc: [982] (secs) (secs) (secs) (real time) (usr+sys time) instance (%) (KB) stress-ng: metrc: [982] vm 23544 60.08 2.90 15.74 391.85 1263.43 7.75 524708 stress-ng: info: [982] skipped: 0 stress-ng: info: [982] passed: 4: vm (4) stress-ng: info: [982] failed: 0 stress-ng: info: [982] metrics untrustworthy: 0 stress-ng: info: [982] successful run completed in 1 min, 0.09 secs stress-ng: metrc: [983] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s CPU used per RSS Max stress-ng: metrc: [983] (secs) (secs) (secs) (real time) (usr+sys time) instance (%) (KB) stress-ng: metrc: [983] vm 23544 60.09 3.12 15.91 391.81 1237.10 7.92 705076 stress-ng: info: [983] skipped: 0 stress-ng: info: [983] passed: 4: vm (4) stress-ng: info: [983] failed: 0 stress-ng: info: [983] metrics untrustworthy: 0 stress-ng: info: [983] successful run completed in 1 min, 0.09 secs Best, Hui > > Thanks, > Michal >
