Why does XMRig fail with 1GB pages even though my CPU supports pdpe1gb?

XMRig can fail to use 1 GB pages even when your CPU shows pdpe1gb because that flag proves only that your processor supports them. Your operating system must also support, reserve, and allow XMRig to use those pages—and the memory must be available in the right place.

CPU support is only the first requirement

A memory page is a chunk of memory managed by your operating system. Larger pages can reduce memory-management work when XMRig runs RandomX, Monero’s mining algorithm.

The pdpe1gb CPU flag means your processor can handle 1 GB pages. It does not mean Linux has reserved any for you.

Also, XMRig’s “1 GB pages” option is Linux-specific. On Windows, XMRig can use large pages, but enabling its 1 GB page option does not provide the same Linux feature.

Inside a virtual machine, the virtual operating system needs its own working setup. Seeing the CPU flag alone is still not enough.

Check the 1 GB pool, not just “huge pages”

Linux manages different page sizes in separate pools. Having plenty of 2 MB huge pages does not mean you have any 1 GB pages.

Check the 1 GB pool with:

grep . /sys/kernel/mm/hugepages/hugepages-1048576kB/{nr_hugepages,free_hugepages}

Here, 1048576kB means 1 GB.

• nr_hugepages shows how many pages are reserved.
• free_hugepages shows how many are currently unused.
• If the directory is missing, your running system may not expose support for that page size.

Do not rely only on HugePages_Total in /proc/meminfo. That entry describes the default huge-page size, which may be 2 MB.

You usually need three pages per memory node

RandomX’s fast mode uses a 2,080 MB dataset, a large working collection of data. That is already slightly more than two 1 GB pages. XMRig’s usual 1 GB-page setup therefore needs three 1 GB pages per NUMA node it uses.

A NUMA node is a group of CPU cores and nearby memory. Some computers have several, especially multi-socket servers.

Two common problems follow:

• You reserve only two pages, thinking “RandomX needs about 2 GB.”
• You reserve enough pages overall, but they are on a different NUMA node from the allocation XMRig needs.

On a NUMA system, inspect the page pools under /sys/devices/system/node/node*/hugepages/ as well.

Reservation and access can still fail

A 1 GB page needs a large, physically continuous block of memory. After Linux has been running for a while, memory can become fragmented. You may have several gigabytes free without having a usable 1 GB block.

Reserving pages at boot is generally more reliable. A typical single-node reservation uses kernel boot parameters such as:

hugepagesz=1G hugepages=3

Follow your Linux distribution’s instructions before changing boot settings. Reserved huge pages remove memory from ordinary use.

Also check:

• Enable XMRig’s --randomx-1gb-pages option, or set "1gb-pages": true inside its "randomx" configuration.
• Confirm your mining user has the required huge-page access and memory-lock allowance.
• Check service or container restrictions if XMRig runs successfully outside them.
• Read XMRig’s startup allocation messages, not just its CPU-feature report.

The bottom line

pdpe1gb means “your CPU can,” not “your system is ready.” Check the actual 1 GB pool, available pages per NUMA node, and allocation permissions. If that setup is impractical, ordinary 2 MB huge pages remain a useful alternative; 1 GB pages are an optional optimization, not a mining requirement.