RFR(XS): 8194232: Container memory not properly recognized.

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Jan 4 15:38:29 UTC 2018


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