Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91796
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.192.180 as permitted sender)
To: Anatol Belski <anatol.php@belski.net>,
 'php-internals' <internals@lists.php.net>
References: <1458448146.14007.1@smtp.gmail.com>
 <097c01d182eb$33437780$99ca6680$@belski.net>
Cc: 'Remi Collet' <remi@php.net>, 'Dmitry Stogov' <dmitry@zend.com>
Message-ID: <56EF1FA3.9060600@lerdorf.com>
Date: Sun, 20 Mar 2016 15:09:39 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <097c01d182eb$33437780$99ca6680$@belski.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Huge Pages
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 03/20/2016 01:58 PM, Anatol Belski wrote:
> Dmitry has already merged this patch into the 7.0 branch. I also know from Remi that Fedora doesn't play well with the huge pages. Huge pages require special system settings which are usually not enabled in OSes by default. Having it off by default in PHP would therefore not cause any functional disadvantage while addressing the stability concerns. Thus reversing the default setting sounds feasible, it could be already done for the upcoming 7.0.5 if there are no objections.

Yes, and since the special system settings, namely setting
vm.nr_hugepages is a system-wide shared setting and not PHP-specific it
makes even more sense to not enable huge pages by default. If you happen
to install PHP on a system that has vm.nr_hugepages set to non-zero for
some other service on that machine, PHP is going blow up as soon as it
runs out of huge pages.

And the 2nd reason to disable huge pages by default is that, as you say,
on most systems vm.nr_hugepages is going to be 0 but MAP_HUGETLB will be
defined because every modern OS supports huge pages even if they are not
actually enabled. But the allocator doesn't know that. It will try to do
a MAP_HUGETLB mmap every single time here:

  https://github.com/php/php-src/blob/master/Zend/zend_alloc.c#L470

which is going to fail with an ENOMEM error and fall back to a
non-HUGETLB mmap. So every alloc there incurs an extra syscall in the
default case.

So we have 3 things to do:

1. Default it to off
2. Provide a way to specify the huge page size as per bug 71355
3. Document the use of USE_ZEND_ALLOC_HUGE_PAGES and how to set
   vm.nr_hugepages appropriately along with a warning about what
   might happen if don't allocate enough

1 and 3 are trivial. 2 is a little trickier if we want to try to detect
the page size. We could just not try and let the user specify it.
Perhaps even use ZEND_ALLOC_HUGE_PAGES directly. As in:

  ZEND_ALLOC_HUGE_PAGES=2048

would turn on huge pages in the allocator with 2k pages.

-Rasmus