RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
Severin Gehwolf
sgehwolf at openjdk.org
Mon Nov 11 10:26:49 UTC 2024
On Thu, 7 Nov 2024 13:28:29 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:
> Create a new cgroup for memory
>
> ```
> sudo mkdir -p /sys/fs/cgroup/memory/test
> ```
>
> Run the following script
>
> ```
> docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m ubuntu:latest \
> sh -c "sleep 10 ; /jdk/bin/java -Xlog:os+container=trace -version" | grep Memory\ Limit &
> sleep 10
> HOSTPID=$(sudo ps -ef | awk '/container=trace/ && !/docker/ && !/awk/ { print $2 }')
> echo $HOSTPID | sudo tee /sys/fs/cgroup/memory/test/cgroup.procs
> sleep 10
> ```
>
> In the above script, a containerized process (`/bin/sh`) is moved to cgroup `/test` before `/jdk/bin/java` gets executed. Java inherits cgroup `/test` from its parent process, its `_root` will be `/docker/<CONTAINER_ID>`, `cgroup_path` will be `/test`.
OK, but why is https://bugs.openjdk.org/browse/JDK-8322420 not in effect in such a case?
> The result would be ($JAVA_HOME points to JDK before fix)
>
> ```
> 9804
> [0.001s][trace][os,container] Memory Limit failed: -2
> [0.001s][trace][os,container] Memory Limit failed: -2
> [0.002s][trace][os,container] Memory Limit failed: -2
> [0.043s][trace][os,container] Memory Limit failed: -2
> ```
>
> JDK updated version:
>
> ```
> 10001
> [0.001s][trace ][os,container] Memory Limit is: 419430400
> [0.001s][trace ][os,container] Memory Limit is: 419430400
> [0.002s][trace ][os,container] Memory Limit is: 419430400
> [0.035s][trace ][os,container] Memory Limit is: 419430400
> ```
It would be good to see the full boot JVM output at the trace level. I'm wondering why the adjustment isn't sufficient for the use-case the bug describes. I.e. if the move happens *before* the JVM starts then there is a chance it works OK by detecting some limit. If not it would really be useful to understand it better.
If, however, the cgroup move happens after the JVM has started, there is nothing in the JVM which "corrects" the detected physical memory (i.e. heap size et. al) and/or detected CPUs. It's not supported to do that dynamically.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2467779326
More information about the core-libs-dev
mailing list