[PHP-CVS] com php-src: Added an experemental ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be configured and built with --enable-huge-code-pages, OS should be configured to provide huge pages. It's possibl

-----Original Message-----
From: Dmitry Stogov [mailto:dmitry@zend.com]
Sent: Monday, September 14, 2015 10:37 PM
To: Anatol Belski anatol.php@belski.net
Cc: Anatol Belski ab@php.net; Kalle Sommer Nielsen kalle@php.net;
Rasmus Lerdorf rasmus@lerdorf.com; Xinchen Hui xinchen.h@zend.com;
Nikita Popov nikita.ppv@gmail.com; Zeev Suraski zeev@zend.com; Andi
Gutmans andi@zend.com; PHP Internals internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental
ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP
should be configured and built with --enable-huge-code-pages, OS should
be
configured to provide huge pages. It's possibl

With the new huge memory pages feature I'd suggest a bit softer -
enabling its building, but setting opcache.enable_huge_code_pages=0 by
default.

OK.

Then it can be easy enable and give one more intermediate step for pre
testing and go into RC4 completely if ok.

In general we may get build problems on some platforms...

What do you think?

I didn't get, do you like to delay this for RC4? or enable it at
compile time and
disable at run-time by default for RC3?
I agree with both.

I was suggesting the latter - build and disable at run-time. With RC4 I
meant - as it's run-time enabled by default currently, that could be turned
on by default in RC4 if everything was well in RC3.

Regarding possible build issues you mention - probably some magic in
config.m4 could disable huge pages? I wasn't aware, but probably yep - like
FreeBSD or OSX likely to not to have the sys/prctl.h . This could be a
reason for delaying till RC4, but it's actually easy solved doing some test
compilation in config.m4 . I'd see build + disable on run-time in RC3 as a
better move because it turns the test circle earlier which is good
considering there are only 4 RCs to go yet.

As long as we fail gracefully when compiled with hugepage support and
then run on a system that doesn't have any hugepages configured. These
days the build box and the production execution box are rarely the same
machine.

Yeah. This is transparent solution. At first it's disabled by default by
opcache.huge_code_pages=0. At second, it should work without problem if OS
doesn't provide huge pages.

Redhat enables THP by default and has for a while, but I know lots of
admins that disable this feature right away on production machines. I
don't think it is default on Ubuntu, but at least they have hugepage
tools to make it easy to configure. And from a quick look at Debnian
(jessie) it wasn't obvious how to get hugepages working. I don't see a
package for hugeadm offhand. The kernel supports it, obviously, but you
need to take some steps to configure them.

PHP prefers using regular Huge Pages and may fail back to THP (Transparent
Huge Pages).
So THP don't have to be enabled.

Which means we also need to spend a bit of time documenting how to
enable hugepages at the OS level for the various operating systems to go
along with this feature.

Right. Manual OS configuration is required. See
https://wiki.debian.org/Hugepages#Enabling_HugeTlbPage
Steps (3) and (4) are optional.

Thanks. Dmitry.

-Rasmus