On Sun, Jan 04, 2026 at 09:30:46AM +0000, [email protected] wrote: > 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: [2011] dispatching hogs: 4 vm > 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 > > stress-ng: info: [2012] setting to a 1 min, 0 secs run per stressor > 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
> As the results show, setting memory.low on the cgroup with the > high-priority workload did not improve its memory performance. It could also be that memory isn't the bottleneck here. I reckon that 80%+80% > 100% but I don't know how quickly stress-ng accesses it. I.e. actual workingset size may be lower than those 80%. If it was accompanied with a run in one cg only, it'd help determning benchmark's baseline. > 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. That's expected, no action is needed when the current consumption is below memory.high. > What do you think about hooking try_charge_memcg as well, > so that it ensures __mem_cgroup_handle_over_high is called? The logic in try_charge_memcg is alredy quite involved and I think only simple concepts (that won't deviate too much as implementation changes) should be exposed to the hooks. > Thanks for your remind. > This is a test log in the test environment without any extra progs: Thanks, it's similar to the example above (I assume you're after "bogo ops/s" in real time, RSS footprint isn't the observed metric), i.e. the jobs don't differ. But it made me to review the results in your original posting (with your patch) and the high group has RSS Max of 834836 KB (so that'd be the actual workingset size for the stressor). So both of them should easily fit into the 4G of the machine, hence I guess the bottleneck is IO (you have swap right?), that's where prioritization should be applied (at least in this demostration/representative case). HTH, Michal
signature.asc
Description: PGP signature
