RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v2]
Jan Kratochvil
jkratochvil at openjdk.org
Tue Jan 30 14:10:09 UTC 2024
On Fri, 12 Jan 2024 16:26:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:
>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix gtest testcases compilation errors
>
> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 97:
>
>> 95:
>> 96: List<String> cgcreate = new ArrayList<>();
>> 97: cgcreate.add("cgcreate");
>
> This test relies on `cgcreate` being present on the test system. I wonder if we could create a similar test with using `systemd-slices` only. Either way, we need to have a corresponding check that this test dependency is there a. la. `@requires docker`.
`cgcreate` is in `libcgroup-tools`, that is unrelated to `docker`. I have implemented a check for its (or rather `cgdelete`) existence.
> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 112:
>
>> 110: if (!matcher.find()) {
>> 111: System.err.println(mountInfo);
>> 112: throw new SkippedException("cgroup2 filesystem mount point not found");
>
> Why is this check there? It should be the same for hierachical cgroup v1 systems (most of them), no? My testing of the `cgcreate` flow suggests it's the same on `v1`. It's just not as visible since there are per controller paths in `/proc/self/cgroup` on `v1` and we have the hierarchical memory limit work-around employed on v1.
This should be fixed now with the new cgroup1 support.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1471281953
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1471280268
More information about the core-libs-dev
mailing list