Edit report at https://bugs.php.net/bug.php?id=71355&edit=1

  ID: 71355
  Updated by: rasmus@php.net
  Reported by: jocelyn dot fournier@softizy.com
  Summary: Fail to use huge page on power8 because of wrong
                      page size
  Status: Open
  Type: Bug
  Package: opcache
  Operating System: Linux on Power
  PHP Version: 7.0.2
  Block user comment: N
  Private report: N

  New Comment:

I think option 2 makes more sense. We have now disabled huge pages by default as of PHP 7.0.6 and there is an env var called USE_ZEND_ALLOC_HUGE_PAGES that enables it. That is currently a boolean, but we could change it to take the page size.

Previous Comments:
[2016-03-22 16:25:22] basu at us dot ibm dot com


All ppc64 architectures (POWER) support 16MB page support at the hardware level. Also,
the Linux kernel supports 16MB pages if it is built with CONFIG_HUGETLBFS (and CONFIG_HUGETLB_PAGE is also enabled) enabled. As long as MAP_HUGETLB is used in mmap()
calls from applications, (No need for mount hugetlbfs) and lenth parameter is
huge page size aligned, the calls mmap() and munmap() will be successful.

Now, there are two ways PHP code can be sure of whether system supports hugepages.
1) It can look at /proc/meminfo: cat /proc/meminfo | grep Hugepagesize to get
the current pagesize for use with mmap()/munmap() if MAP_HUGETLB is to be used.
2) we could place the policy on the user, i.e., have the user specify in php conf
file the intention for php to use huge pages during mmap()/munmap(). For example,
if we specify USE_HUGEPAGES=1 in php conf file, php could use this at run time
as a hint to start using hugepages. Of course, the user would set the sysctl.conf file to have vm.nr_hugepages set.

[2016-03-22 11:56:53] jpauli@php.net

I wasn't aware of such a define.

We could use it if we can detect it at compile time, yes.
Could you try on your system if that gives good results ?

[2016-03-21 19:47:09] jocelyn dot fournier@softizy.com

/proc/meminfo should give you the Hugepagesize info.
What about using HPAGE_SIZE ?

[2016-03-21 17:47:34] jpauli@php.net

The problem is that there is no way do dynamically discover the huge page size, knowing that some systems have different sizes, and may map different memory arear using different page size. There is nothing comparable to _SC_PAGESIZE or getpagesize(), which are part of POSIX.

One could parse /proc/mounts to find hugetlbfs entries.
Or we could rely on the excellent libhugetlbfs, but what if the system doesn't support it ?


Huge page mapping is really hard to manage in a crossplatform way, way more than classical memory mappings where we have libc's malloc() on top of the Kernel calls, and where (nearly) every system agreed on having a default 4Kb page size

[2016-02-16 21:57:27] basu at us dot ibm dot com

Since linux on POWER supports huge page of size 16MB, it appears that this
hard coded value of 2MB in ZendAccelerator.c is letting the mmap()/madvise()/munmap()
fail with EINVAL due to invalid argument.

This routine below with 2MB constant is only valid for promoting opcode cache to huge page.. This routine is not controlling the huge page semantics for PHP data allocations. However, there is a CHUNKSIZE buckets that are being managed by PHP 7.0.2
that does not have a size for huge page (max size for chunk size is only 2MB) I changed that to 16MB and was able to eliminate the mmap/madvise/munmap errors. Basically
the chunk size management code should include huge page support on POWER.


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at


Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 5 | next ›
Discussion Overview
groupphp-bugs @
postedMar 21, '16 at 5:47p
activeMar 26, '16 at 9:04a



site design / logo © 2018 Grokbase