Hugetlb pages are incredibly architecture specific at the Memory Management Unit (MMU) level. For example, every arch has a different way of handling the page table entries. This leads to some tricky rules and restrictions on what can be done with huge pages. The following sections describe the issues surrounding these architecture limitations on a per-architecture basis.

PowerPC

The powerpc architecture makes use of segmentation to reduce the flushing of virtual to physical address translations. Each segment is 256M in size and can contain only one page size. For addresses below 4GB, 256MB is the page size granularity. For 64bit addresses above 4GB, the page size granularity is 1TB.

The available page sizes are: 4k, 64k, 16M, and 16G(!)

x86 / x86-64

The x86 architecture has a relatively simple method of doing huge pages: in the page table tree the lowest tier of page table entries just gets consolidated into the "one level above that" PTE entry with a special bit set. This means that there are effectively three requirements on huge pages

• The size is fixed to 2Mb (x86-64 and x86-with-PAE) or 4Mb (x86-without-PAE). PAE is the 64 bit page table entry support for x86 that allows x86 to support more than 4Gb of physical memory.
• The virtual address space alignment is also 2Mb/4Mb (same as the size page)
• The physical page alignment is also 2Mb/4Mb (this is no issue; buddy already makes sure of this)

There has been talk from the various CPU vendors at the last kernel summit to go to 1Gb pages in addition to the 2Mb/4Mb ones. This probably will be a logical extension of the concept above, with a "one level up" consolidation bit in the pagetable, nothing stunning otherwise.