Disable Processor Counting based on Cgroups Container Support
David Holmes
david.holmes at oracle.com
Mon May 15 01:03:41 UTC 2023
Hi Bruno,
On 13/05/2023 3:18 am, Bruno Borges wrote:
> Hi folks,
>
> Looking at the source code, I couldn't identify a way (on tip, or any
> previous release) to keep container support for memory limit, but
> disable it for CPU limit.
The intent is that the container represents your "host" and so the
containers limits becomes the VMs limits. That is what people asked for
from container support.
> While I could achieve this by not setting a CPU limit in my container
> orchestration solution (e.g., Kubernetes), it wouldn't necessarily give
> me what I am looking for: I do want to set a CPU limit at the container
> level, but I want the JVM to count for all processors in the host/node.
> While I can manually tweak this by modifying -XX:ActiveProcessorCount,
> this requires me to know upfront how many processors the Node/Host will
> have.
I'm not even sure the VM is exposed to the actual number of processors
available on a node/host when running in all container environments. And
I'm not sure how this ties in to dynamic changes to the cpu limits? With
ActiveProcessorCount=M you are asking the VM to act as-if it had M cpus
regardless of how many the actual limit is - how does that help with the
limit changing dynamically?
> Additionally, setting -XX:ActiveProcessorCount=-1 does not give me the
> behavior I was expecting either.
Can you elaborate? Setting to -1 disables the feature so that the host
environment (container or OS) is queried.
> The reason I raise this is due to the new In-place Pod Resource Resizing
> feature in Kubernetes 1.27, that allows a pod to change the CPU limit
> without restarting the pod. See this article for details:
> https://medium.com/@karla.saur/trying-out-the-new-in-place-pod-resource-resizing-68a0b3c42b72 <https://medium.com/@karla.saur/trying-out-the-new-in-place-pod-resource-resizing-68a0b3c42b72>
Okay ...
> In an ideal world, the JVM would dynamically scale its thread pools, GC
> threads, and other components at JVM and Application level accordingly,
> but we are not there yet, I believe.
I can imagine some scenarios where we would want specific thread-pools
to scale based on the dynamic number of available CPUs, but I hardly
think it would be "ideal" in the sense that every such pool would want
to do so and perhaps even automatically do so. It all depends on what
tasks your pool is servicing as to whether it needs to scale that way,
and the job of doing that scaling would be in the application logic that
configures/controls the pool in the first place - thread pools don't
know why they are the size they are. That application can already query
the available processors (as reported by the environment) to dynamically
modify things as it sees fit. Unfortunately, there is AFAIK, no API to
inform you when the number of cpu's changes.
Cheers,
David
-----
> I'd love to hear what others think.
>
> Thanks,
> Bruno
More information about the hotspot-runtime-dev
mailing list