RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v7]

[Severin Gehwolf]

> Please review this Linux container detection improvement which allows limits being detected even if they are not exposed at the leaf nodes. So far this is only observable on systemd slices on cgroup v2. For cgroup v1 this has been addressed with [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) in a version specific way. This patch proposes to address the problem a different way. Instead of only looking at the determined cgroup path for the interface files, we iterate the hierarchy up to its root and find the minimal limit in that hierarchy (if any).
> 
> Consider this subsystem path:
> 
> 
> /sys/fs/cgroup/memory/user.slice/user-cg.slice/user-cg-cpu.slice/run-r634adce2617145ea9660623c335cb3db.scope
> 
> 
> with a root of `/sys/fs/cgroup/memory` and a cgroup path of `/user.slice/user-cg.slice/user-cg-cpu.slice/run-r634adce2617145ea9660623c335cb3db.scope`. Then prior this patch we only looked at `/sys/fs/cgroup/memory/user.slice/user-cg.slice/user-cg-cpu.slice/run-r634adce2617145ea9660623c335cb3db.scope/memory.max` on cgroup v2 systems for the limit and at `/sys/fs/cgroup/memory/user.slice/user-cg.slice/user-cg-cpu.slice/run-r634adce2617145ea9660623c335cb3db.scope/memory.limit_in_bytes` on cgroup v1 systems. On cgroup v1 we also looked at `/sys/fs/cgroup/memory/user.slice/user-cg.slice/user-cg-cpu.slice/run-r634adce2617145ea9660623c335cb3db.scope/memory.stat` looking for the `hierarchical_memory_limit` key in there if the original look-up of the limit in `memory.limit_in_bytes` file returned no limit. However, the `hierarchical_memory_limit` info is cgroup v1 specific and not present on cg v2's `memory.stat` files.
> 
> This patch addresses this problem in a uniform way by walking the cgroup path up to the root looking up any limit, solving the problem that got addressed version specific with JDK-8217338 at the time as well as addressing the problem on cgroup v2. That is on cg v1 the following series of paths are being looked at in that order (if any limit is found we record the path where we've found the limit and fix it to that path for subsequent look-ups; JVM runtime):
> 
> 
> /sys/fs/cgroup/memory/user.slice/user-cg.slice/user-cg-cpu.slice/run-r634adce2617145ea9660623c335cb3db.scope/memory.limit_in_bytes
> /sys/fs/cgroup/memory/user.slice/user-cg.slice/user-cg-cpu.slice/memory.limit_in_bytes
> /sys/fs/cgroup/memory/user.slice/user-cg.slice/memory.limit_in_bytes
> /sys/fs/cgroup/memory/user.slice/memory.limit_in_bytes
> /sys/fs/cgroup/memory/memory.limit_in_bytes
> 
> 
> The patch im...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - Fix missing const char*
 - Make accessors return const char*
 - Handle limits somewhere lower in the hierarchy
 - Set _path to nullptr (cgv1)
 - Move constructor impls to cpp file
 - Add a comment for the container case on cg v1
 - Fix comment
 - Add assertion for cg_path[0] == '/'
 - Make set_subsystem_path() take const char* as arg
 - ... and 10 more: https://git.openjdk.org/jdk/compare/0d593cd1...c2244b4b

-------------

Changes: https://git.openjdk.org/jdk/pull/20646/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20646&range=06
  Stats: 446 lines in 10 files changed: 335 ins; 83 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/20646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20646/head:pull/20646

PR: https://git.openjdk.org/jdk/pull/20646