Disable Processor Counting based on Cgroups Container Support

ioi.lam at oracle.com ioi.lam at oracle.com
Wed May 17 23:35:31 UTC 2023


On 5/12/23 10: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.
>
Do you mean you want the app to use as much CPU as available, but 
somehow constrain it so that it will not starve the other apps on the 
same host of CPU time?

I think this can be done by running your containers with CPU shares but 
without CPU limits.

We had a bug in interpreting CPU shares such that the JVM will 
under-utilize CPUs when CPU shares have been set. This has been fixed in 
https://bugs.openjdk.org/browse/JDK-8281571. Could you check if your JDK 
has this fix?

Thanks

- Ioi


> 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.
>
> Additionally, setting -XX:ActiveProcessorCount=-1 does not give me the 
> behavior I was expecting either.
>
> 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
>
> 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'd love to hear what others think.
>
> Thanks,
> Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20230517/7cb3effd/attachment.htm>


More information about the hotspot-runtime-dev mailing list