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

[David Holmes]

PS. Bob you will need to file a CSR request for this change in 
behaviour. But I think you're going to have to make this selectable somehow.

David

On 13/02/2018 12:16 PM, David Holmes wrote:
> 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.
>>>>>
>>>>>
>>