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