RFR: 8197589: CPU count wrong when both cpu shares and quotas are used

David Holmes david.holmes at oracle.com
Tue Feb 13 02:16:30 UTC 2018


On 13/02/2018 12:04 PM, Bob Vandette wrote:
>> On Feb 12, 2018, at 8:01 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Bob,
>>
>> On 13/02/2018 5:53 AM, Bob Vandette wrote:
>>> Updated webrev URL.
>>>> On Feb 12, 2018, at 2:41 PM, Bob Vandette <bob.vandette at oracle.com> wrote:
>>>>
>>>> Please review this change to the cpu count selection logic used when running in docker containers.
>>>>
>>>> BUG:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8197589
>>>>
>>>> WEBREV:
>>>>
>>>> http://cr.openjdk.java.net/~bobv/8197589/webrev.00/
>>>>
>>>> The algorithm implemented in JDK-8146115 for selecting the number of active cpus assumed that a container
>>>> would not be configured to use both cpu shares AND cpu quotas at the same time. This was an invalid assumption
>>>> since this how containers are configured to allow bursting activity [1].  A Java process running in a container with
>>>> cpu shares set to the equivalent of 2 cpus and a quota set to 6, will end up configuring the VM for 2 CPUs rather
>>>> than 6.
>>>>
>>>> [1] https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/#motivation-for-cpu-requests-and-limits
>>
>> This really makes very little sense to me. They seem to be confusing utilization with number of physical processors that are available to use. The end result seems somewhat random to me. The number of threads the VM creates in response to the expected number of CPUs it has available is only indirectly related to the load those threads may then impose on the system. But I would have thought you would try to size the VM's use of threads based on the "request" not the "limit”.
> 
> If we chose the request (which is the way it works before this change), then we risk under utilizing the available CPU resources.
> Since there’s no risk with over utilizing, I think the new algorithm is a better choice.

So "limit" doesn't mean limit? I would expect there to be a real risk 
with over utilising.

The change does what you want so in that sense consider it reviewed. But 
as to whether what it does is reasonable ... I can easily imagine 
someone else would want the current behaviour, just as readily as 
someone wants the new behvaiour.

David

> Bob.
> 
> 
>>
>> David
>>
>>>>
>>>> Bob.
>>>>
>>>>
> 


More information about the hotspot-runtime-dev mailing list