Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88188
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: "'Dmitry Stogov'" <dmitry@zend.com>,
	"'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>
Date: Mon, 14 Sep 2015 22:05:11 +0200
Message-ID: <031201d0ef28$abcec710$036c5530$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIrZycj8gcimac7Mo68xuhek5bopwJpU/6tnXQB4sA=
Content-Language: en-us
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
From: anatol.php@belski.net ("Anatol Belski")

Hi Dmitry,

> -----Original Message-----
> From: Dmitry Stogov [mailto:dmitry@zend.com]
> Sent: Monday, September 14, 2015 12:58 PM
> To: 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: [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 possible to
>=20
> The effect of this patch is really exiting to keep it disabled by =
default... :)
>=20
> $ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
> sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=3D0 -T 10000
> /var/www/html/bench/wordpress-3.6/index.php > /dev/null
>=20
>    191,778,620,621      instructions              #    0.81  insns per
> cycle
>        178,497,016
> iTLB-loads
>         87,351,276      iTLB-load-misses          #   48.94% of all =
iTLB
> cache hits
>    238,136,402,797
> cycles
>=20
>      110.221114219 seconds time elapsed
>=20
> $ perf stat -e instructions,iTLB-loads,iTLB-load-misses,cycles
> sapi/cgi/php-cgi -d opcache.enable_huge_code_pages=3D1 -T 10000
> /var/www/html/bench/wordpress-3.6/index.php > /dev/null
>=20
>    191,780,181,536      instructions              #    0.83  insns per
> cycle
>         39,017,004
> iTLB-loads
>         41,631,359      iTLB-load-misses          #  106.70% of all =
iTLB
> cache hits
>    231,287,491,307
> cycles
>=20
>      107.742837269 seconds time elapsed
>=20
> May be we should enable this by default in RC (may be also file cache) =
and make
> decision based on feedback?
>=20
The file cache feature has proven itself as stable already, IMHO it =
should be built by default in RC3.

With the new huge memory pages feature I'd suggest a bit softer - =
enabling its building, but setting opcache.enable_huge_code_pages=3D0 by =
default. Then it can be easy enable and give one more intermediate step =
for pre testing and go into RC4 completely if ok. What do you think?

Regards

Anatol=20