Skip to content

Document opcache.huge_code_pages prerequisites when JIT is on - #4861

Open
nisbet-hubbard wants to merge 1 commit into
php:masterfrom
nisbet-hubbard:patch-2
Open

Document opcache.huge_code_pages prerequisites when JIT is on#4861
nisbet-hubbard wants to merge 1 commit into
php:masterfrom
nisbet-hubbard:patch-2

Conversation

@nisbet-hubbard

Copy link
Copy Markdown
Contributor

opcache.huge_code_pages was broken in 8.4 (php/php-src#19638), and has recently been fixed in php/php-src@0ee7732.

It comes with new requirements: in order for PHP to reserve huge pages at all, the OS has to set aside enough to also cover opcache.jit_buffer_size.

This PR documents how to calculate the number to allocate.

@Girgias
Girgias requested a review from arnaud-lb January 9, 2026 01:44

@arnaud-lb arnaud-lb left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nisbet-hubbard thank you, but I don't think that opcache.huge_code_pages is related to opcache.memory_consumption or opcache.jit_buffer_size: opcache.huge_code_pages only moves the "text segment" of the php binary, aka the php interpreter itself, to huge pages.

It is true that this requires appropriate OS configuration to allocate enough HUGE PAGES for the text segment. I'm not sure how it can be estimated accurately, however. But Opcache will print E_WARNING errors in case moving the text segment fails (as well as debug information in the opcache logs).

Comment thread reference/opcache/ini.xml Outdated
Comment thread reference/opcache/ini.xml Outdated
opcache.huge_code_pages only remaps the text segment of the PHP binary:
accel_move_code_to_huge_pages() scans /proc/self/maps for the r-x mapping
belonging to the running binary and remaps that one. It has no bearing on
opcache.memory_consumption or opcache.jit_buffer_size.

The shared memory segment is a separate matter, and its use of huge pages
was undocumented. Its size is memory_consumption plus jit_buffer_size when
the JIT is enabled, and OPcache tries to allocate it with MAP_HUGETLB
before falling back to regular pages without any diagnostic. That is what
makes the huge page pool appear undersized when the JIT is on.

Also states that a failed text segment remap reports an E_WARNING, and
that huge_code_pages does not cover the shared memory segment, since the
two are easily conflated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants