Huge pages

[Volker Simonis]

Hi Tiago,

unfortunately I'm unable to reproduce the problem you reported (i.e. the
(errno = 16) warning).

Here's what I did:
- first I configured my fedora 17 box to support HugePages:

echo 256 > /proc/sys/vm/nr_hugepages
echo 1073741824 > /proc/sys/kernel/shmmax
echo 2000 > /proc/sys/vm/hugetlb_shm_group

It seems that I don't had enough continous memory available because I ended
up with less than the requested 256 huge pages:

HugePages_Total:     177
HugePages_Free:      177
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:      16384 kB

It was also crucial to set the group of the user which runs java in
/proc/sys/vm/hugetlb_shm_group, otherwise the usage of large pages will
fail with:

OpenJDK 64-Bit Server VM warning: Failed to reserve shared memory (errno =
1).

where 'errno = 1' is EPERM. But as you didn't get this error, I suppose you
already had all these settings right.

If I try to allocate a heap which is bigger than HugePages_Total*
Hugepagesize I get:

OpenJDK 64-Bit Server VM warning: Failed to reserve shared memory (errno =
22)

But again, 'errorno=22' is EINVAL and different from yours.

That said, I can now run SPECjvm2008.jar with large pages without any
warnings:

java -XX:+UseConcMarkSweepGC -XX:+UseLargePages -XX:+UseSHM -Xmx756m
-showversion -jar SPECjvm2008.jar -wt 120 -it 300 --parseJvmArgs -i 1 --peak
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build
1.7.0-internal-openjdk_2013_04_09_14_20-b00)
OpenJDK 64-Bit Server VM (build 24.0-b34, mixed mode)

SPECjvm2008 Peak
...

I can only imagine that your problem may be perhaps related to the use of
compressed pointers (-XX:+UseCompressedOops) which is on by default for our
port but off by default for the Zero-VM. As far as I can see, this can lead
to a situation where different base addresses are tried for the allocation
of the heap and where you may get such a warning although the actual
allocation will later succeed for another heap address. But that's only a
vague guess. Nevertheless you could try out if switching compressed
pointers off (with -XX:-UseCompressedOops) will change something.

Can you please also run your java commands (both the port and the zero-vm)
under 'strace -f -e trace=ipc' like this:

strace -f -e trace=ipc java  -XX:+UseConcMarkSweepGC -XX:+UseLargePages
-XX:+UseSHM -Xmx756m -version

and post the IPC-relevant output for further investigation. It should be
something like:

[pid 20061] shmget(IPC_PRIVATE, 872415232, IPC_CREAT|SHM_HUGETLB|0600) =
2162688
[pid 20061] shmat(2162688, 0xcc000000, 0) = 0xcc000000
[pid 20061] shmctl(2162688, IPC_RMID, 0) = 0

Regards,
Volker


On Tue, Apr 9, 2013 at 5:29 AM, Tiago Stürmer Daitx <
tdaitx at linux.vnet.ibm.com> wrote:

> > > - how do you run the program (i.e. a complete command line would be
> > > useful)
> > java -XX:+PrintCommandLineFlags -XX:+UseParNewGC -XX:+UseLargePages -XX:
> > +UseSHM -Xms2560m -jar target/concurrency-torture.jar
> >
> Another option is to run specjvm2008 (used as example by the LVM article
> on Huge Pages [1]
>
> java -XX:+UseLargePages -XX:+UseSHM -Xmx756m -jar SPECjvm2008.jar -wt
> 120 -it 300 --parseJvmArgs -i 1 --peak
>
>
>
> [1] https://lwn.net/Articles/378641/
> --
> Tiago Stürmer Daitx
> tdaitx at linux.vnet.ibm.com
> IBM - Linux Technology Center
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20130409/056eae88/attachment.html