I didn’t actually have any ERROR_MARGIN problems during testing.  I had issues 
with the testCpuConsumption  test in
http://cr.openjdk.java.net/~bobv/8203357/webrev.01/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java.html
 
<http://cr.openjdk.java.net/~bobv/8203357/webrev.01/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java.html>
I had to initialize the cpu usage values during setup rather than inside the 
test to ensure that sufficient cpu usage
had occurred by the time the test was run.   The original code executed and 
received the same values after attempting
to exec a linux utility.  My change uses the time taken to run several tests 
instead.  This seems to have eliminated any intermittent failures.

Bob.


> On Jun 8, 2018, at 12:30 AM, Harsha Wardhana B <harsha.wardhan...@oracle.com> 
> wrote:
> 
> [Replying to all mailing-lists]
> Hi Misha,
> 
> The ERROR_MARGIN in tests was introduced to make the tests stable. There are 
> times where metric values (specifically CPU usage) can change drastically in 
> between two reads. The metrics value got from the API and the cgroup file can 
> be different and 0.1 ERROR_MARGIN should take care of that, though at times 
> even that may not be enough. Hence the CPU usage related tests only print a 
> warning if ERROR_MARGIN is exceeded.
> 
> Thanks
> Harsha
> 
> On Friday 08 June 2018 03:00 AM, Mikhailo Seledtsov wrote:
>> Hi Bob,
>> 
>>   I looked at the tests. In general they look good. I am a bit concerned 
>> about the use of ERROR_MARGIN in one of the tests. We need to make sure that 
>> the tests are stable, and do not produce intermittent failures.
>> 
>> 
>> Thank you,
>> Misha
>> 
>> On 6/7/18, 10:43 AM, Bob Vandette wrote:
>>> Can I get one more reviewer for this RFE so I can integrate it?
>>> 
>>>> http://cr.openjdk.java.net/~bobv/8203357/webrev.01
>>> Mandy Chung has reviewed this change.
>>> 
>>> I’ve run Mach5 hotspot and core lib tests.
>>> 
>>> I’ve reviewed the tests which were written by Harsha Wardhana
>>> 
>>> I filed a CSR for the command line change and it’s now approved and closed.
>>> 
>>> Thanks,
>>> Bob.
>>> 
>>> 
>>>> On May 30, 2018, at 3:45 PM, Bob Vandette<bob.vande...@oracle.com>  wrote:
>>>> 
>>>> Please review the following RFE which adds an internal API, along with 
>>>> jtreg tests that provide
>>>> access to Docker container configuration data and metrics.  In addition to 
>>>> the API which we hope to
>>>> take advantage of in the future with Java Flight Recorder and a JMX Mbean, 
>>>> I’ve added an additional
>>>> option to -XshowSettings:system than dumps out the container or host 
>>>> cgroup confguration
>>>> information.  See the sample output below:
>>>> 
>>>> RFE: Container Metrics
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8203357
>>>> 
>>>> WEBREV:
>>>> 
>>>> http://cr.openjdk.java.net/~bobv/8203357/webrev.01
>>>> 
>>>> 
>>>> This commit will also include a fix for the following bug.
>>>> 
>>>> BUG: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8203691
>>>> 
>>>> WEBREV:
>>>> 
>>>> http://cr.openjdk.java.net/~bobv/8203357/webrev.00/test/hotspot/jtreg/runtime/containers/cgroup/PlainRead.java.sdiff.html
>>>>  
>>>> 
>>>> SAMPLE USAGE and OUTPUT:
>>>> 
>>>> docker run —memory=256m --cpuset-cpus 4-7 -it ubuntu bash
>>>> ./java -XshowSettings:system
>>>> Operating System Metrics:
>>>>     Provider: cgroupv1
>>>>     Effective CPU Count: 4
>>>>     CPU Period: 100000
>>>>     CPU Quota: -1
>>>>     CPU Shares: -1
>>>>     List of Processors, 4 total:
>>>>     4 5 6 7
>>>>     List of Effective Processors, 4 total:
>>>>     4 5 6 7
>>>>     List of Memory Nodes, 2 total:
>>>>     0 1
>>>>     List of Available Memory Nodes, 2 total:
>>>>     0 1
>>>>     CPUSet Memory Pressure Enabled: false
>>>>     Memory Limit: 256.00M
>>>>     Memory Soft Limit: Unlimited
>>>>     Memory&  Swap Limit: 512.00M
>>>>     Kernel Memory Limit: Unlimited
>>>>     TCP Memory Limit: Unlimited
>>>>     Out Of Memory Killer Enabled: true
>>>> 
>>>> TEST RESULTS:
>>>> 
>>>> testing runtime container APIs
>>>> Directory "JTwork" not found: creating
>>>> Passed: runtime/containers/cgroup/PlainRead.java
>>>> Passed: runtime/containers/docker/DockerBasicTest.java
>>>> Passed: runtime/containers/docker/TestCPUAwareness.java
>>>> Passed: runtime/containers/docker/TestCPUSets.java
>>>> Passed: runtime/containers/docker/TestMemoryAwareness.java
>>>> Passed: runtime/containers/docker/TestMisc.java
>>>> Test results: passed: 6
>>>> Results written to /export/users/bobv/jdk11/build/jtreg/JTwork
>>>> 
>>>> testing jdk.internal.platform APIs
>>>> Passed: jdk/internal/platform/cgroup/TestCgroupMetrics.java
>>>> Passed: jdk/internal/platform/docker/TestDockerCpuMetrics.java
>>>> Passed: jdk/internal/platform/docker/TestDockerMemoryMetrics.java
>>>> Passed: jdk/internal/platform/docker/TestSystemMetrics.java
>>>> Test results: passed: 4
>>>> Results written to /export/users/bobv/jdk11/build/jtreg/JTwork
>>>> 
>>>> testing -XshowSettings:system launcher option
>>>> Passed: tools/launcher/Settings.java
>>>> Test results: passed: 1
>>>> 
>>>> 
>>>> Bob.
>>>> 
>>>> 
> 

Reply via email to