Huge pages on PPC64

[Gustavo Romero]

Hi Thomas,

On 28-10-2016 07:36, Thomas Stüfe wrote:
> Hi guys,
> 
> On Fri, Oct 28, 2016 at 9:39 AM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
> 
>> Hi Gustavo,
>>
>> please find my comments inline:
>>
>> On Thu, Oct 27, 2016 at 11:12 PM, Gustavo Romero
>> <gromero at linux.vnet.ibm.com> wrote:
>>> Hi Volker,
>>>
>>> On 25-10-2016 05:13, Volker Simonis wrote:
>>>> Just a quick question: do you also get the same warnings if you are
>>>> running without compressed oops (i.e. -XX:-UseCompressedClassPointers
>>>> -XX:-UseCompressedOops)? If not maybe this is related to the fact that
>>>> for compressed oops we try to allocate memory in low memory regions.
>>>
>>> $ java -XX:+PrintCommandLineFlags -Xms256m -Xmx256m -XX:+UseLargePages
>> -XX:-UseCompressedClassPointers -XX:-UseCompressedOops StrictMath_cos
>>> -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=268435456
>> -XX:+PrintCommandLineFlags -XX:-UseCompressedClassPointers
>> -XX:-UseCompressedOops -XX:+UseLargePages -XX:+UseParallelGC
>>> OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory
>> req_addr: 0x0000000000000000 bytes: 268435456 (errno = 16).
>>> 0.1709843554185943
>>>
>>> It fails when trying to allocate 256 MiB starting at 0x0, so definitely
>> a low
>>> memory region.
> 
> 
> Just a quick pipe-in, req_addr=NULL means "attach to any address, no
> preference", so this has nothing to do with attaching to low memory regions.

ah, kk.

One curious thing is that packaged java (I tested Debian [1] and Ubuntu [2])
seems to try no specific address (NULL), while my jdk8u release build [3] seems
to request one specifically. So on packaged java

(Packaged java, just like my previous paste)
$ java  -XX:+PrintCommandLineFlags -Xms256m -Xmx256m -XX:+UseLargePages -XX:-UseCompressedClassPointers -XX:-UseCompressedOops StrictMath_cos -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=268435456
-XX:+PrintCommandLineFlags -XX:-UseCompressedClassPointers -XX:-UseCompressedOops -XX:+UseLargePages -XX:+UseParallelGC
OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x0000000000000000 bytes: 268435456 (errno = 16).
0.1709843554185943

but on my build

(jdk8u release build [3])
$ ./build/linux-ppc64-normal-server-release/jdk/bin/java  -XX:+PrintCommandLineFlags -Xms256m -Xmx256m -XX:+UseLargePages -XX:-UseCompressedClassPointers -XX:-UseCompressedOops StrictMath_cos
-XX:InitialHeapSize=268435456 -XX:MaxHeapSize=268435456 -XX:+PrintCommandLineFlags -XX:-UseCompressedClassPointers -XX:-UseCompressedOops -XX:+UseLargePages -XX:+UseParallelGC
OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x00003fff86000000 bytes: 268435456 (errno = 16).
 0.1709843554185943

Huge Pages configuration is like this:
$ fgrep Huge /proc/meminfo
AnonHugePages:     16384 kB
HugePages_Total:    1024
HugePages_Free:     1024
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:      16384 kB

Anyway, I believe that the crucial point is if HP is really used optimally by
the JVM when these warnings pop up as there is, as far as I understand, a
fallback mechanism that will select alternative ways to request an allocation
with Huge Pages (i.e. after mmap() + MAP_HUGETLB fails, it tries shmget() +
SHM_HUGETLB).

Thank you!

Regards,
Gustavo


[1] Debian
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)

[2] Ubuntu 16.04
openjdk version "1.8.0_45"
OpenJDK Runtime Environment (build 1.8.0_45-b13)
OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode)

[3] My local build
http://hg.openjdk.java.net/jdk8u/jdk8u, d15b51f1149b tip
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-gromero_2016_10_30_19_15-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)