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

Zdenek Zambersky zzambers at openjdk.org
Wed Aug 28 13:56:21 UTC 2024


On Wed, 28 Aug 2024 13:03:53 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

>>> Had a look. I am no expert in these things, so this concentrates more on the mechanical parts and on readability.
>> 
>> Thanks very much for the review, @tstuefe!
>
> Hi @jerboaa,
> New approach is nice improvement. Going up the hierarchy until reaching some limit should probably work ok for real word cases. It has its limitations though. Namely the case, when there is a stricter limit higher in the hierarchy. E.g. if I do:
> 
> $ cat /etc/systemd/system/user.slice.d/memory-limit.conf
> [Slice]
> MemoryLimit=512M
> $ sudo systemctl daemon-reload
> 
> than JDK will pick limit from `user-cg.slice` (following your example) rather than from `user.slice` (even though stricter limit from user.slice is actually in force). This may be known limitation (based on description). Scenario is probably uncommon in real world.

> @zzambers:
> 
> > Namely the case, when there is a stricter limit higher in the hierarchy.
> 
> This case has been handled in my fix #17198 but it was rejected by @jerboaa. An older patch version before I had to remove it: [webrev #07](https://openjdk.github.io/cr/?repo=jdk&pr=17198&range=07), [the patch](https://github.com/openjdk/jdk/compare/243cb098d48741e9bd6308ef7609c9a4637a5e07...39c9016296de1b58bdbfb370437ea195fa06fee5.diff).
> 
> There was also a testcase for this situation. And the testcase worked also on Alpine Linux as a supported JDK platform as it did not require `systemd`.

Thanks for link to the other PR. Sorry, I was not following container development closely. Just from quick reading, I see, there was discussion about performance/complexity implications/tradeoffs there.

I just wanted to point out this limitation, as something to be considered.

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

PR Comment: https://git.openjdk.org/jdk/pull/20646#issuecomment-2315385083


More information about the hotspot-runtime-dev mailing list