RFR(XS): 8194232: Container memory not properly recognized.
Bob Vandette
bob.vandette at oracle.com
Thu Jan 4 19:37:05 UTC 2018
The tests passed and I pushed the changeset you gave me adding Karen as an additional
Reviewer.
Bob.
> On Jan 4, 2018, at 12:13 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
>
> Hi Bob and Karen,
>
> Do i unterstand right, i shall push myself once Bobs tests are done? That's fine.
>
> We have our own testing. I run the patch with our nightbuild through all our nightly tests, which includes all Hotspot jtreg tests.
> But there sometimes is a difference in test results if you run it.
>
> Best regards
> Götz
>
>> Am 04.01.2018 um 18:05 schrieb Karen Kinnear <karen.kinnear at oracle.com>:
>>
>> Code looks good - I am a hotspot runtime Reviewer.
>> So once Bob’s testing is done, you are all set.
>>
>> thanks so much for making and testing this change,
>> Karen
>>
>>> On Jan 4, 2018, at 10:38 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
>>>
>>> That's great, thanks a lot!
>>>
>>> Best,
>>> Goetz.
>>>
>>>> -----Original Message-----
>>>> From: Bob Vandette [mailto:bob.vandette at oracle.com]
>>>> Sent: Donnerstag, 4. Januar 2018 16:36
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>> Cc: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-
>>>> dev at openjdk.java.net
>>>> Subject: Re: RFR(XS): 8194232: Container memory not properly recognized.
>>>>
>>>> Sure I’ll take care of it.
>>>>
>>>> Bob.
>>>>
>>>>
>>>>> On Jan 4, 2018, at 10:34 AM, Lindenmaier, Goetz
>>>> <goetz.lindenmaier at sap.com> wrote:
>>>>>
>>>>> Hi Bob,
>>>>>
>>>>> neither Martin nor I can push hotspot changes. We don't have
>>>>> access to jprt.
>>>>> Could you sponsor this? I would like it to get pushed to 10.
>>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Bob Vandette [mailto:bob.vandette at oracle.com]
>>>>>> Sent: Donnerstag, 4. Januar 2018 16:27
>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>> Cc: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: RFR(XS): 8194232: Container memory not properly
>>>> recognized.
>>>>>>
>>>>>> The new webrev looks good.
>>>>>>
>>>>>> I see that Martin is a JDK reviewer so unless you need a hotspot reviewer
>>>>>> you should be good to go.
>>>>>>
>>>>>> Bob.
>>>>>>
>>>>>>
>>>>>>> On Jan 4, 2018, at 4:09 AM, Lindenmaier, Goetz
>>>>>> <goetz.lindenmaier at sap.com> wrote:
>>>>>>>
>>>>>>> Hi Bob,
>>>>>>>
>>>>>>> A new webrev using your version:
>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8194232-
>>>>>> ppcle_unlimited/webrev.02/
>>>>>>>
>>>>>>> It fixes the issue I saw, and traces the output you describe below.
>>>>>>> Actually, in my case gc/arguments/TestAgressiveHeap.java failed
>>>>>>> and this also passes now. The machine has cgroups but no docker
>>>>>>> which is why the test failed.
>>>>>>> The five tests below don't run on ppc because docker.support is
>>>>>>> false.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Bob Vandette [mailto:bob.vandette at oracle.com]
>>>>>>>> Sent: Mittwoch, 3. Januar 2018 20:12
>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Doerr, Martin
>>>>>>>> <martin.doerr at sap.com>; hotspot-runtime-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR(XS): 8194232: Container memory not properly
>>>>>> recognized.
>>>>>>>>
>>>>>>>> I built and ran a VM with the changes below (with jong -> jlong type
>>>> fixed)
>>>>>>>> and it passed
>>>>>>>> the jtreg container tests.
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> If you run this command on your OS and look in the logs, you should
>>>> see
>>>>>> the
>>>>>>>> Unlimited message:
>>>>>>>>
>>>>>>>> ./java -Xlog:os+containers=trace -version
>>>>>>>>
>>>>>>>> …..
>>>>>>>> [0.001s][trace][os,container] Memory Limit is: 9223372036854771712
>>>>>> <<——
>>>>>>>> This number will be different for you.
>>>>>>>> [0.001s][trace][os,container] Memory Limit is: Unlimited
>>>>>>>> [0.001s][debug][os,container] container memory unlimited, using host
>>>>>> value
>>>>>>>> …..
>>>>>>>>
>>>>>>>> Bob.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Jan 3, 2018, at 1:54 PM, Bob Vandette
>>>> <bob.vandette at oracle.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Jan 3, 2018, at 2:43 AM, Lindenmaier, Goetz
>>>>>>>> <goetz.lindenmaier at sap.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Bob,
>>>>>>>>>>
>>>>>>>>>> The value is read from the file system as jlong.
>>>>>>>>>> I think making the reading of the value as jlong or julong
>>>>>>>>>> depend on the kernel version is not a good idea.
>>>>>>>>>
>>>>>>>>> I agree that we shouldn't make the solution based on the running
>>>> kernel
>>>>>>>> version.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So should I test for
>>>>>>>>>> memlimit < 0 || memlimit > LONG_MAX / os::vm_page_size() *
>>>>>>>> os::vm_page_size()
>>>>>>>>>> and get rid of the constant altogether?
>>>>>>>>>
>>>>>>>>> I was thinking that we could change the type read from the file
>>>> system
>>>>>> to a
>>>>>>>> julong and then just
>>>>>>>>> use memlimit > LONG_MAX / os::vm_page_size() *
>>>>>> os::vm_page_size().
>>>>>>>> You’ll need to
>>>>>>>>> add a (jlong) cast but since we’re checking for > LONG_MAX, there
>>>> will
>>>>>> be
>>>>>>>> no precision
>>>>>>>>> lost.
>>>>>>>>>
>>>>>>>>> Something like this:
>>>>>>>>>
>>>>>>>>> --- a/src/hotspot/os/linux/osContainer_linux.cpp
>>>>>>>>> +++ b/src/hotspot/os/linux/osContainer_linux.cpp
>>>>>>>>> @@ -31,16 +31,12 @@
>>>>>>>>> #include "logging/log.hpp"
>>>>>>>>> #include "osContainer_linux.hpp"
>>>>>>>>>
>>>>>>>>> -/*
>>>>>>>>> - * Warning: Some linux distros use 0x7FFFFFFFFFFFF000
>>>>>>>>> - * and others use 0x7FFFFFFFFFFFFFFF for unlimited.
>>>>>>>>> - */
>>>>>>>>> -#define UNLIMITED_MEM CONST64(0x7FFFFFFFFFFFF000)
>>>>>>>>>
>>>>>>>>> #define PER_CPU_SHARES 1024
>>>>>>>>>
>>>>>>>>> bool OSContainer::_is_initialized = false;
>>>>>>>>> bool OSContainer::_is_containerized = false;
>>>>>>>>> +julong _unlimited_memory;
>>>>>>>>>
>>>>>>>>> class CgroupSubsystem: CHeapObj<mtInternal> {
>>>>>>>>> friend class OSContainer;
>>>>>>>>> @@ -217,6 +213,8 @@
>>>>>>>>> _is_initialized = true;
>>>>>>>>> _is_containerized = false;
>>>>>>>>>
>>>>>>>>> + _unlimited_memory = (LONG_MAX / os::vm_page_size()) *
>>>>>>>> os::vm_page_size();
>>>>>>>>> +
>>>>>>>>> log_trace(os, container)("OSContainer::init: Initializing Container
>>>>>>>> Support");
>>>>>>>>> if (!UseContainerSupport) {
>>>>>>>>> log_trace(os, container)("Container Support not enabled");
>>>>>>>>> @@ -419,37 +417,37 @@
>>>>>>>>> * OSCONTAINER_ERROR for not supported
>>>>>>>>> */
>>>>>>>>> jlong OSContainer::memory_limit_in_bytes() {
>>>>>>>>> - GET_CONTAINER_INFO(jlong, memory, "/memory.limit_in_bytes",
>>>>>>>>> - "Memory Limit is: " JLONG_FORMAT, JLONG_FORMAT,
>>>>>>>> memlimit);
>>>>>>>>> + GET_CONTAINER_INFO(julong, memory,
>>>> "/memory.limit_in_bytes",
>>>>>>>>> + "Memory Limit is: " JULONG_FORMAT, JULONG_FORMAT,
>>>>>>>> memlimit);
>>>>>>>>>
>>>>>>>>> - if (memlimit >= UNLIMITED_MEM) {
>>>>>>>>> + if (memlimit >= _unlimited_memory) {
>>>>>>>>> log_trace(os, container)("Memory Limit is: Unlimited");
>>>>>>>>> return (jlong)-1;
>>>>>>>>> }
>>>>>>>>> else {
>>>>>>>>> - return memlimit;
>>>>>>>>> + return (jong)memlimit;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> jlong OSContainer::memory_and_swap_limit_in_bytes() {
>>>>>>>>> - GET_CONTAINER_INFO(jlong, memory,
>>>>>>>> "/memory.memsw.limit_in_bytes",
>>>>>>>>> - "Memory and Swap Limit is: " JLONG_FORMAT,
>>>>>>>> JLONG_FORMAT, memswlimit);
>>>>>>>>> - if (memswlimit >= UNLIMITED_MEM) {
>>>>>>>>> + GET_CONTAINER_INFO(julong, memory,
>>>>>>>> "/memory.memsw.limit_in_bytes",
>>>>>>>>> + "Memory and Swap Limit is: " JULONG_FORMAT,
>>>>>>>> JULONG_FORMAT, memswlimit);
>>>>>>>>> + if (memswlimit >= _unlimited_memory) {
>>>>>>>>> log_trace(os, container)("Memory and Swap Limit is: Unlimited");
>>>>>>>>> return (jlong)-1;
>>>>>>>>> } else {
>>>>>>>>> - return memswlimit;
>>>>>>>>> + return (jlong)memswlimit;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> jlong OSContainer::memory_soft_limit_in_bytes() {
>>>>>>>>> - GET_CONTAINER_INFO(jlong, memory,
>>>>>> "/memory.soft_limit_in_bytes",
>>>>>>>>> - "Memory Soft Limit is: " JLONG_FORMAT,
>>>> JLONG_FORMAT,
>>>>>>>> memsoftlimit);
>>>>>>>>> - if (memsoftlimit >= UNLIMITED_MEM) {
>>>>>>>>> + GET_CONTAINER_INFO(julong, memory,
>>>>>>>> "/memory.soft_limit_in_bytes",
>>>>>>>>> + "Memory Soft Limit is: " JULONG_FORMAT,
>>>>>> JULONG_FORMAT,
>>>>>>>> memsoftlimit);
>>>>>>>>> + if (memsoftlimit >= _unlimited_memory) {
>>>>>>>>> log_trace(os, container)("Memory Soft Limit is: Unlimited");
>>>>>>>>> return (jlong)-1;
>>>>>>>>> } else {
>>>>>>>>> - return memsoftlimit;
>>>>>>>>> + return (jlong)memsoftlimit;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> Bob.
>>>>>>>>>
>>>>>>>>>> Instead, I would implement a method
>>>>>> is_unlimited_memory(memlimit).
>>>>>>>>>>
>>>>>>>>>> I don't want to make the change too big, as I need to get it fixed in
>>>> 10.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Goetz.
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Bob Vandette [mailto:bob.vandette at oracle.com]
>>>>>>>>>>> Sent: Dienstag, 2. Januar 2018 17:10
>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>>>>>>> Cc: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-
>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>> Subject: Re: RFR(XS): 8194232: Container memory not properly
>>>>>>>> recognized.
>>>>>>>>>>>
>>>>>>>>>>> I just read that unlimited may be one of these possible values
>>>>>> depending
>>>>>>>> on
>>>>>>>>>>> Kernel version.
>>>>>>>>>>>
>>>>>>>>>>> LONG_MAX (Linux Kernel Version < 3.1.2)
>>>>>>>>>>> ULONG_MAX (3.12 <= Linux Kernel Version < 3.19)
>>>>>>>>>>> LONG_MAX / pagesize * pagesize (Linux Kernel Version >= 3.19)
>>>>>>>>>>>
>>>>>>>>>>> Assuming os::page_size() is initialized before the container init, we
>>>>>>>> should
>>>>>>>>>>> calculate
>>>>>>>>>>> the unlimited value based on this and take the ULONG_MAX
>>>> situation
>>>>>>>> into
>>>>>>>>>>> consideration.
>>>>>>>>>>>
>>>>>>>>>>> Bob.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Dec 27, 2017, at 6:24 AM, Lindenmaier, Goetz
>>>>>>>>>>> <goetz.lindenmaier at sap.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Martin,
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, I also figured that the constant is one system page less than
>>>> max
>>>>>>>> long.
>>>>>>>>>>>> If the system pages are > 64K, this constant will be too small,
>>>> again.
>>>>>>>>>>>> But I'm not sure whether adding 8 zeros is right thing to do in
>>>> ramp
>>>>>>>> down
>>>>>>>>>>> phase.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Doerr, Martin
>>>>>>>>>>>>> Sent: Mittwoch, 27. Dezember 2017 12:10
>>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
>>>> hotspot-
>>>>>>>> runtime-
>>>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>>>> Subject: RE: RFR(XS): 8194232: Container memory not properly
>>>>>>>>>>> recognized.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Götz,
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks for fixing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I wonder if 4 zeroes will be sufficient on all linux distros in the
>>>> long
>>>>>>>> run.
>>>>>>>>>>> Does
>>>>>>>>>>>>> anything speak against using e.g. 8 zeroes?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Martin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
>>>>>>>>>>>>> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>>>>>>>>>>>>> Sent: Mittwoch, 27. Dezember 2017 11:38
>>>>>>>>>>>>> To: hotspot-runtime-dev at openjdk.java.net
>>>>>>>>>>>>> Subject: RFR(XS): 8194232: Container memory not properly
>>>>>>>> recognized.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review and sponsor this tiny fix. It needs to go to jdk10.
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8194232-
>>>>>>>>>>>>> ppcle_unlimited/webrev.01/
>>>>>>>>>>>>>
>>>>>>>>>>>>> TestAggressiveHeap.java fails because the container recognition
>>>>>>>>>>>>> misinterprets the available memory size. On SLES 12.1 ppc64le,
>>>>>>>>>>>>> GET_CONTAINER_INFO() sets memlimit to 0x7FFFFFFFFFFF0000.
>>>>>> This
>>>>>>>>>>>>> is compared to UNLIMITED_MEM == 0x7FFFFFFFFFFFF000,
>>>> making
>>>>>>>>>>>>> the VM believe memory is _not_ unlimited.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
More information about the hotspot-runtime-dev
mailing list