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

[Bob Vandette]

> 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?


>> 
>> 
>> 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
>>> 
>>