summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorNatalie Vock <natalie.vock@gmx.de>2026-08-04 10:25:21 +0200
committerNatalie Vock <nat@pixelcluster.dev>2026-08-05 10:36:21 +0200
commit3d33e9c726d677be4087dcb33c1710176e85d9c1 (patch)
tree71fd403ea6854b38ba8f9db04d075a3f8b922a28 /tools/perf/scripts/python/export-to-postgresql.py
parentbbc744c062f84834fc3c69aa011477c806460d20 (diff)
drm/ttm: Use common ancestor of evictor and evictee as limit pool
When checking whether to skip certain buffers because they're protected by dmem.low, we're checking the effective protection of the evictee's cgroup, but depending on how the evictor's cgroup relates to the evictee's, the semantics of effective protection values change. When testing against cgroups from different subtrees, page_counter's recursive protection propagates memory protection afforded to a parent down to the child cgroups, even if the children were not explicitly protected. This prevents cgroups whose parents were afforded no protection from stealing memory from cgroups whose parents were afforded more protection, without users having to explicitly propagate this protection. However, if we always calculate protection from the root cgroup, this breaks prioritization of sibling cgroups: If one cgroup was explicitly protected and its siblings were not, the protected cgroup should get higher priority, i.e. the protected cgroup should be able to steal from unprotected siblings. This only works if we restrict the protection calculation to the subtree shared by evictor and evictee. Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Natalie Vock <natalie.vock@gmx.de> Link: https://patch.msgid.link/20260804-dmemcg-aggressive-protect-v8-6-07af96681bf8@gmx.de
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions