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

[Zdenek Zambersky]

On Wed, 28 Aug 2024 15:28:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Hi @jerboaa,
>> New approach is nice improvement. Going up the hierarchy until reaching some limit should probably work ok for real world 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.
>
>> This may be known limitation (based on description). Scenario is probably uncommon in real world.
> 
> @zzambers Thanks for pointing it out. Yes, it's a current limitation. The simple condition - for now - was if there was any non-max limit we stop. This could be changed of course to walk the full hierarchy and take the absolute minimum. I'm wondering, though, has this been seen in the wild? The JDK being run in a system slice with some memory limit, yes. In a setup that does those strange configs, perhaps not so much. So far I'm inclined to keep the simpler version as that's been recommended by Kernel folks to me, keeps the complexity down and it's really a misconfigured system.
> 
> If consensus is that we need to cover this case as well, that should be possible to do - here or in a follow-up.

@jerboaa It's true, that problematic scenario is a bit artificial. I am not aware of actual scenarios like that, nor I see much reason to do something like that, even though possible. :)

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

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