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