aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/failed-syscalls-by-pid.py
diff options
context:
space:
mode:
authorMichal Koutný <[email protected]>2020-08-06 23:22:18 -0700
committerLinus Torvalds <[email protected]>2020-08-07 11:33:26 -0700
commita6f23d14ec7d7d02220ad8bb2774be3322b9aeec (patch)
tree183c5291a5919481e2b77547ba99318390ecd92a /tools/perf/scripts/python/failed-syscalls-by-pid.py
parente22c6ed90aa91abc08f107344428ebb8c2629e98 (diff)
mm/page_counter.c: fix protection usage propagation
When workload runs in cgroups that aren't directly below root cgroup and their parent specifies reclaim protection, it may end up ineffective. The reason is that propagate_protected_usage() is not called in all hierarchy up. All the protected usage is incorrectly accumulated in the workload's parent. This means that siblings_low_usage is overestimated and effective protection underestimated. Even though it is transitional phenomenon (uncharge path does correct propagation and fixes the wrong children_low_usage), it can undermine the intended protection unexpectedly. We have noticed this problem while seeing a swap out in a descendant of a protected memcg (intermediate node) while the parent was conveniently under its protection limit and the memory pressure was external to that hierarchy. Michal has pinpointed this down to the wrong siblings_low_usage which led to the unwanted reclaim. The fix is simply updating children_low_usage in respective ancestors also in the charging path. Fixes: 230671533d64 ("mm: memory.low hierarchical behavior") Signed-off-by: Michal Koutný <[email protected]> Signed-off-by: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Roman Gushchin <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Tejun Heo <[email protected]> Cc: <[email protected]> [4.18+] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/failed-syscalls-by-pid.py')
0 files changed, 0 insertions, 0 deletions