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

Severin Gehwolf sgehwolf at openjdk.org
Sun Mar 10 14:40:09 UTC 2024


On Wed, 21 Feb 2024 11:32:46 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> After internal discussion I have realized the patch has overgrown its intended scope. And one should also consider how easy it would be for a backport down to JDK-8. I am going to split it into:
> 
>     1. cgroup1 bugfix to always use kernel-side computed minimum `leaf/memory.stat` even if `leaf/memory.max` is not `max` - present in the current patch - to be split out under a new JDK Bug ID
> 
>     2. cgroup1 change from reading `leaf/memory.stat` to traversal of `all-depths/memory.max`. - not present in the current patch, you have requested it, its only advantage is it does not reset some of the stats. Is it really needed? Also because cgroup1 is becoming outdated, RHEL7 ends this summer.
> 
>     3. cgroup2 bugfix to implement traversal of `all-depths/memory.max` - present in the current patch - to be tracked under this JDK Bug ID.
> 
>     4. cgroup2 kernel-side computed minimum in `leaf/memory.max.effective` - present in the current patch but not planned to but checked into OpenJDK before the kernel patch gets accepted.
> 
> 
> Do you agree?

I won't have time to properly review this this week. The latest version seemed to go into the right direction, though. Point 4.) above can only go in after *any* released kernel supports it to begin with.

One goal of this patch would be to unify how this works for cgroup v1 and cgroup v2. The on-init traversal for both versions makes sense as it solves the same problem (systemd slice) without using the hierarchical limit work-around (covers point 2 and 3). Point 1.) seems orthogonal to this patch, but I'm not sure I understand what it's about to begin with...

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1956638224


More information about the core-libs-dev mailing list