One detail I’ve been overlooking in my processor retrospective series is the choice of page size. For many processors, the page size is dictated by the processor, but some processors give you a choice.
| Processor | Page size | Reasonable choices | |
|---|---|---|---|
| Normal | Large | ||
| x86-32 without PAE | 4KB | 4MB | 4KB only |
| x86-32 with PAE | 4KB | 2MB | 4KB only |
| x86-64 | 4KB | 2MB | 4KB only |
| SH-4 | 4KB | — | 1KB, 4KB |
| MIPS | 4KB | — | 1KB, 4KB |
| PowerPC | 4KB | — | 4KB only |
| Alpha AXP | 8KB | — | 8KB, 16KB, 32KB |
| Alpha AXP 64 | 8KB | — | 8KB, 16KB, 32KB |
| Itanium | 8KB | — | 4KB, 8KB |
| ARM (AArch32) | 4KB | N/A | 1KB, 4KB |
| ARM64 (AArch64) | 4KB | 2MB | 4KB only |
I arbitrarily define “reasonable choices” for the page size to be sizes less than 64KB, although 64KB pages were considered for ia64.
The large page size on x86-32 is determined by hardware depending on whether PAE is enabled. Windows enables PAE by default starting in Windows XP, since it is required for Data Execution Prevention.
The MIPS and ARM natively use 4KB pages, but they support subdividing those pages into 1KB “subpages”. Windows CE for ARM920 took advantage of this and used 1KB “pages”. All other flavors of Windows use the native 4KB pages. (ARM formally deprecated subpages in ARMv6.)
Windows never shipped a 64-bit version of Windows for Alpha AXP, but internal builds of it were produced to serve as the early proving ground for 64-bit Windows while the team waited for 64-bit CPUs to arrive from Intel.
Windows dropped support for many of these processors before large page support was added to the operating system. For those processors, the large page size is given as —, indicating that no choice was ever made. This is different from the N/A entry for 32-bit ARM, which indicates that 32-bit ARM explicitly does not support large pages.
Note that the operating system can always synthesize larger page sizes by simply allocating memory in multiples of the CPU native page size, but this doesn’t mean that you can have mixed page sizes. If you decide to have (say) artificial 8KB pages constructed from pairs of 4KB pages, you need to do this consistently if you allow visibility into page frames. Otherwise, you can get into the situation where you need to allocate 8KB of contiguous physical memory, but all you can find are two 4KB native pages that aren’t adjacent to each other.
To quote John Carmack: “4KB pages feel silly on a 64 bit operating system.”
Would be quite interested in knowing more about that 64bit Alpha version of Windows
Raymond has many posts about the Alpha: doing a search for "AXP" gets the majority of them, although it also returns articles on how the chip itself worked. All interesting and informative in my opinion! His posts on the PowerPC and Itanium architectures are equally thrilling; I kind of wish that I had been able to try out those computers, but there was no way I would have been able to afford them and I...
I think Itanium machines are hard to find now as they’re most likely to be servers. However for PowerPCs, I think eBay is still selling second hand Apple PowerMac G4 that runs on it.
Oops, just search and it seems you can buy second hand HP Itanium servers on eBay too.
Shouldn’t there be 3rd column for huge (1GB) pages? Supported on x86-64 and AArch64.
Any maybe 4th for 512GB ones (brutal, gigantic?) if the rumor I’ve heard about LA57 is true. Although I haven’t seen any API, so that’d probably be just —.
At the moment, PML5E entries for a present page MUST have the PS bit set to 0, indicating that they reference a PML4 table, not a gigantic page. There’s room for Intel or AMD to expand this to support 512GB pages later, but it’s not permitted right now.
Thanks for clarifying that.