On Wed, 21 Feb 2024 11:32:46 GMT, Jan Kratochvil <jkratoch...@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
