On Sun, 1 Dec 2024 12:48:40 GMT, Sergey Chernyshev <schernys...@openjdk.org> wrote:
> In the Cloudflare case (cg v1 before patch), the path > `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c` > will be adjusted as follows: I assume that's the adjustment logic (pre-patch) that happens provided the setting to `nullptr` issue is addressed in cg v1? > ``` > /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/ > /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/ > /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/ > /sys/fs/cgroup/cpu,cpuacct/system.slice/ > /sys/fs/cgroup/cpu,cpuacct/ > ``` > > In cg v1 systems, all the above paths except for the very last, are invalid. > So, no chance for detecting any lower limits. When a process moved to a > subgroup, the trailing part of cgroup_path will constitute the subgroup path. And after the patch this would become this, right? /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct/ If so, the change of logic isn't that different (except for where the existence checks are happening). This path adjustment only happens at boot, so the next look-up would use `/sys/fs/cgroup/cpu,cpuacct/`. So it's a trade-off, special case this use-case for added complexity or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1865630320
