Some Intel CPUs support 1GB pages. This is identified by looking at CPUID 0x80000001, EDX bit 26. The Linux kernel exposes this via /proc/cpuinfo as the pdpe1gb flag.

Where do we find out which CPUs support this, and which ones do not? Or what product line supports this feature? There's nothing on these Intel ARK pages that indicate support for this feature.

CPUs that do support 1GB pages:

Other CPUs that do not support 1GB pages:


According to this page:

in addition to their standard 4 KB pages newer x86-64 processors, such as AMD's newer AMD64 processors and Intel's Westmere and later processors can use 1 GB pages in long mode

Seems to be true as it was a new feature of Westmere CPUs.

  • 4
    Yes, I definitely looked at all of those Wikipedia pages! However, this answer is not correct. Sandy Bridge is newer that Westmere, and I now have two Sandy Bridge CPUs that do not support it. – Jonathon Reinhart Feb 27 '14 at 14:39
  • 1
    @JonathonReinhart: the huge downside to Hugepages for general use, esp. 1G pages, is that the entire hugepage is tying up that much physical RAM. If a process allocates 1GiB normally, only the parts that it's ever touched actually take up virtual memory. (overcommit even allows allocations that the kernel doesn't have enough swap space to handle). Linux can't page hugepages to disk even when a process is stopped, so a hugepage allocation effectively pins / locks that much physical memory. – Peter Cordes Sep 11 '15 at 7:01
  • 1
    2M hugepages make sense when they won't be left half empty (e.g. when you know for sure that you are going to write every 4k of the 2M anyway), but lack of paging is a big deal. Designing general-purpose software to work horribly badly on memory-constrained desktops is not a good idea. I don't think you can even mmap a file on disk with 2M hugepages, but it would be a bad idea for executables because there will be some 4k pages within a 2M block that aren't touched. These can get evicted from the pagecache (assuming they were prefetched), freeing RAM. – Peter Cordes Sep 11 '15 at 7:04
  • 1
    With current CPUs having multi-level TLBs, the total time spent on TLB misses is probably not too bad, is it? I haven't profiled big stuff like firefox. I'd be interested to see a readable summary of how much time it spends on TLB misses, (esp. page-walks), and stuff like L1 I-cache misses. I know I could just point perf at it... Even if you did want to use 2M hugepages for firefox, I'd guess a lot of its internal data is allocated in smaller chunks than that. There'd be overhead to making sure you minimized external fragmentation of allocations inside a hugepage buffer. – Peter Cordes Sep 11 '15 at 7:08
  • 1
    TLB misses are expensive on high-memory, random-access operations, such as many database applications. Huge pages make a significant difference - but even there, they're talking about 2MB pages, not 1GB. The OS is the most likely user of 1GB pages through direct mapping of the whole physical address space. – GreenReaper Sep 3 '16 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.