Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91790
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Rasmus'" <rasmus@lerdorf.com>,
	"'php-internals'" <internals@lists.php.net>
Cc: "'Remi Collet'" <remi@php.net>,
	"'Dmitry Stogov'" <dmitry@zend.com>
References: <1458448146.14007.1@smtp.gmail.com>
In-Reply-To: <1458448146.14007.1@smtp.gmail.com>
Date: Sun, 20 Mar 2016 21:58:01 +0100
Message-ID: <097c01d182eb$33437780$99ca6680$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHBX9EvV+F63BxwLeX0QAxr7/iM0J+C0dFQ
Content-Language: en-us
Subject: RE: [PHP-DEV] Huge Pages
From: anatol.php@belski.net ("Anatol Belski")

Hi Rasmus,

> -----Original Message-----
> From: Rasmus [mailto:rasmus@lerdorf.com]
> Sent: Sunday, March 20, 2016 5:29 AM
> To: php-internals <internals@lists.php.net>
> Subject: [PHP-DEV] Huge Pages
>=20
> We have a bit of a problem with how Linux handles huge pages when you =
run
> out of them.
>=20
> I've been discussing it with Dmitry and he recently committed a way to =
disable
> Huge Pages in the main allocator to master:
>=20
>=20
> https://github.com/php/php-
> src/commit/945a661912612cdecd221cd126feda7d4335c33c
>=20
> Unfortunately it looks like Linux is very unhappy when a CoW happens =
to a huge
> page allocated in its parent process and it tries to re-map this page. =
If there are
> no available huge pages you get random seg faults/bus errors and =
everything
> blows up. I don't understand why Linux can't fall back to a regular =
page here in
> this case, but it doesn't. It seems like an OS bug to me, but =
nonetheless this
> affects mod_php/php-fpm since we have a huge page allocated before the =
fork,
> but it also affects any cli script that does a pcntl_fork(). As far as =
I can tell there
> is no way to fix it. We could try to make sure we never do a =
MAP_HUGETLB prior
> to the fork in mod_php/php-fpm but that still doesn't solve the =
pcntl_fork() case.
>=20
> Anatol, we should merge Dmitry's patch into PHP-7.0 and further, I =
think we
> should flip the default to zend_mm_use_huge_pages =3D 0 in it.
>=20
> If you have well-behaved code that never tries to allocate a lot of =
memory you
> can turn on huge pages, but I think we should default to safety here. =
Those
> SIGBUS storms are quite alarming and hard to figure out.
>=20
> There have also been some other issues with huge pages as per these
> bugs:
>=20
>     https://bugs.php.net/70984
>     https://bugs.php.net/71272
>     https://bugs.php.net/71355
>=20
> This is very much an expert feature that we need to document better =
and people
> should know what they are stepping in when they turn this feature on.
>=20
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.

Regards

Anatol