RFR(XS): 8191943: [TESTBUG] docker/TestCPUAwareness fails on machine with 2 CPUs
David Holmes
david.holmes at oracle.com
Fri Dec 1 01:10:00 UTC 2017
Seems okay.
Thanks,
David
On 1/12/2017 6:01 AM, mikhailo wrote:
> Bob, David,
>
> Thank you for review.
>
> Here is an updated webrev addressing your comments:
>
> http://cr.openjdk.java.net/~mseledtsov/8191943.02/
>
>
> Misha
>
>
> On 11/29/2017 09:28 PM, David Holmes wrote:
>> On 30/11/2017 10:08 AM, mikhailo wrote:
>>> Here is an updated webrev:
>>>
>>> http://cr.openjdk.java.net/~mseledtsov/8191943.01/
>>
>> As Bob noted you may still need the guard here:
>>
>> 55 testAPCCombo("0,1", 200*1000, 100*1000, 4*1024, 2);
>> 56 testAPCCombo("0,1", 200*1000, 100*1000, 1*1024, 2);
> I introduced a proper check for this.
>>
>> though perhaps docker ignores invalid cpu-set values?
>>
>> 161 Common.logNewTestCase("expectedAPC = " + expectedAPC);
>>
>> That should still be a System.out.println - you already set the test
>> case prior:
> I changed code to output both the original expected APC and the adjusted
> APC.
>>
>> 155 Common.logNewTestCase("test cpu shares, shares = " + shares);
>>
>> Having the same check duplicated three times is a bit messy, but not
>> horrendously so. :)
> Introduced a common method to conditionally adjust APC.
>
> Thank you,
> Misha
>>
>> Thanks,
>> David
>>
>>>
>>> Misha
>>>
>>>
>>> On 11/29/2017 01:32 PM, mikhailo wrote:
>>>>
>>>> On 11/29/2017 01:29 PM, Bob Vandette wrote:
>>>>>> On Nov 29, 2017, at 4:10 PM, mikhailo
>>>>>> <mikhailo.seledtsov at oracle.com> wrote:
>>>>>>
>>>>>> Hi Bob,
>>>>>>
>>>>>> The failure was caused by invoking this test case:
>>>>>>
>>>>>> testCpuShares(4096, 4);
>>>>>> The test case sets --cpu-shares to 4096, expects active
>>>>>> processor count to be 4; ==> actual APC is 2.
>>>>> Ahh, that makes sense. I thought docker was complaining due to the
>>>>> arguments being passed going
>>>>> beyond the available cpus.
>>>>>
>>>>>> Command:
>>>>>>
>>>>>> docker run --tty=true --rm --cpu-shares=4096
>>>>>> jdk-internal:test-cpu /jdk/bin/java -Xlog:os+container=trace -version
>>>>>>
>>>>>> Detailed log is attached at:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/secure/attachment/73820/test-case-failure-cpu-shares-4096.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> Once I saw this issue, I decided to put limits on other test cases
>>>>>> based on the number of processors available on a machine, just to
>>>>>> be on a safe side.
>>>>>>
>>>>>> Perhaps a better approach here is to change the expected APC
>>>>>> inside the testCpuShares() to be no greater than max number of
>>>>>> available processors?
>>>>> Yes, the selection algorithm returns the smallest number of
>>>>> computed shares, quotas or active processors. Using this approach,
>>>>> you’d actually be validating the algorithm more precisely.
>>>> OK. I will update the tests to do this kind of validation, and post
>>>> a new webrev.
>>>>
>>>>
>>>> Misha
>>>>>
>>>>> Bob.
>>>>>
>>>>>
>>>>>>
>>>>>> Misha
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/29/2017 06:02 AM, Bob Vandette wrote:
>>>>>>> Misha,
>>>>>>>
>>>>>>> Which specific subtest failed on a 2 cpu system?
>>>>>>>
>>>>>>> I don’t see any subtests that should have failed. You should be
>>>>>>> able
>>>>>>> to pass any quota, period and share value to docker independent
>>>>>>> of the
>>>>>>> number of CPUs. testCpus and testAPCCombo don’t try to test more
>>>>>>> than 2 cpus.
>>>>>>>
>>>>>>> I’m ok with the change but just wondering why the guards are
>>>>>>> necessary.
>>>>>>>
>>>>>>> Bob.
>>>>>>>
>>>>>>>> On Nov 28, 2017, at 7:50 PM, mikhailo
>>>>>>>> <mikhailo.seledtsov at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Could you, please, review this simple fix? It limits test cases
>>>>>>>> in TestCPUAwareness.java
>>>>>>>> based on the number of processors available.
>>>>>>>>
>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191943
>>>>>>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8191943.00/
>>>>>>>> Testing:
>>>>>>>> 1. Locally: exercised the affected test locally on
>>>>>>>> Linux-x64
>>>>>>>> 2. Exercised the affected test on 2 processor machine
>>>>>>>> 3. Exercise the affected test via automated distributed
>>>>>>>> test system
>>>>>>>> In progress
>>>>>>>>
>>>>>>>> Misha
>>>>>>>>
>>>>
>>>
>
More information about the hotspot-runtime-dev
mailing list