RFR(M): 8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration

[mikhailo]

On 11/07/2017 08:14 AM, Bob Vandette wrote:
>> On Nov 6, 2017, at 11:05 PM, Mikhailo Seledtsov <mikhailo.seledtsov at oracle.com> wrote:
>>
>> Hi Bob,
>>
>>   Thank you for review. Please see my comments inline:
>>
>> On 11/3/17, 11:04 AM, Bob Vandette wrote:
>>> http://cr.openjdk.java.net/~mseledtsov/8189762.00/test/hotspot/jtreg/runtime/containers/docker/CPUSetsReader.java.html
>>>
>>> Not sure this is a problem but  If you specify --cpuset-cpus 2-3,1 in docker you end up with cpuset.cpus containing 1-3.
>>> Your cpusets test cases are all increasing in order so you won’t hit this issue.
>>>
>> I did not do the exhaustive test of all combinations of cpu sets. I tried to cover more common cases while balancing vs complexity and execution time.
>> In TestCPUSets.java I read all available cpu sets from the system, flattened them into a list/set, and then created a container with
>> a subset of one, a full subset available on the system, and rounded half of the subset.
>> If you wish I could file an RFE for 11 to add more corner test cases for this. Please let me know.
>>> The read function in this file has a hard coded /sys/fs/cgroup/cpuset directory.  This may not be where this
>>> ends up being mounted.  Is this read function even used?
>> Yes. This function is used from " TestCPUSets.testTheSet()" to read the sets.
>> I did design the method and test such that if the file can not be read, the test case for a given set will be skipped, to avoid false failures.
>> I did not realize the location for this directory could vary. I can introduce a property jdk.test.docker.cpuset.location that test users or test system could specify to point to the location of cpuset directory; if not specify the default value would be as it is now, /sys/fs/cgroup/cpuset. Is this reasonable?
> I think this needs to be more dynamic.  One of my internal systems has, cpuset.cpus is in /cgroup/cpuset.
> Who knows how the mach5 systems are configured.
>
> Maybe you can use /proc/self/status and extract Cpus_allowed_list?
OK. I will change my tests to extract values from /proc/self/status. I 
assume this method is more standard and reliable than reading from 
/sys/fs/cgroup/cpuset. Right?


Thank you,
Misha
>
>>>
>>> http://cr.openjdk.java.net/~mseledtsov/8189762.00/test/hotspot/jtreg/runtime/containers/docker/TestCPUAwareness.java.html
>>>
>>> Your test assumes that there are at least two physical processors on the host.  You might want to check first.
>>>
>>>   55             testAPCCombo("0,1", 200*1000, 100*1000, 4*1024, 2);
>>>   56             testAPCCombo("0,1", 200*1000, 100*1000, 1*1024, 2)
>> Makes sense. Will do.
>>> Everything else looks good,
>>> bob.
>> Thank you,
> Once you get all of your changes done, maybe you can commit them in a local forest and do an hg export of the
> changeset.  I can then import it and push it for you with my changes.  Assuming this works, this should preserve
> you as the committer and allow the push to have both implementation and tests.
>
> Bob.
>
>> Misha
>>>
>>>> On Nov 1, 2017, at 11:11 PM, mikhailo <mikhailo.seledtsov at oracle.com> wrote:
>>>>
>>>> Please review these tests that were developed to test JVM's container awareness in Docker environment.
>>>>      JBS: https://bugs.openjdk.java.net/browse/JDK-8189762
>>>>      Webrev:
>>>>        Tests: http://cr.openjdk.java.net/~mseledtsov/8189762.00/
>>>>        WB API: http://cr.openjdk.java.net/~mseledtsov/8189762.00.whitebox/
>>>>      Testing:
>>>>          1. Locally: Linux-x64, docker engine version: 17.06.2-ce
>>>>             Ran the developed tests via jtreg
>>>>             Pass
>>>>
>>>>          2. Automated testing system - run these tests
>>>>             In progress
>>>>
>>>> Thank you,
>>>> Misha
>>>>