RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v2]
Ashutosh Mehra
asmehra at openjdk.org
Tue Sep 3 20:07:20 UTC 2024
On Thu, 29 Aug 2024 16:20:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:
>>> I am not aware of actual scenarios like that, nor I see much reason to do something like that, even though possible. :)
>>
>> Having slept over this, I now feel we'd regress cgv1 if we don't do it. Given your suggested test, I'll play with covering this case and adding that to the testing framework in #19530. Then based on the additional complexity we can decide whether or not to cover it or not.
>
>> > I am not aware of actual scenarios like that, nor I see much reason to do something like that, even though possible. :)
>>
>> Having slept over this, I now feel we'd regress cgv1 if we don't do it. Given your suggested test, I'll play with covering this case and adding that to the testing framework in #19530. Then based on the additional complexity we can decide whether or not to cover it or not.
>
> https://github.com/openjdk/jdk/pull/20646/commits/0e17c9914f187d9ee1af32674f03b06e8173bc18 implements this. PTAL.
@jerboaa IIUC this patch sets the memory subsystem path to correspond to the cgroup with the lowest memory limit in the hierarchy. One implication of this approach is that all the memory stats would now be retrieved from that cgroup. So now the swap limit will also be read from that cgroup even though the JVM's cgroup may have a lower value. Is this the desired behavior?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20646#issuecomment-2327336846
More information about the hotspot-runtime-dev
mailing list