4 ms·
And for 64-bit ARM, the base page sizes are 4KiB, 16KiB, and 64KiB, with IIRC 16KiB being optional. If you want 52-bit physical addresses, you need to use 64KiB
by cesarb 6y ago
And for 64-bit ARM, the base page sizes are 4KiB, 16KiB, and 64KiB, with IIRC 16KiB being optional. If you want 52-bit physical addresses, you need to use 64KiB base page size, otherwise the maximum is 48-bit physical addresses; this is probably why RHEL uses 64KiB page size on 64-bit ARM.
- monocasa 6y ago64kb is also a better match for today's working sets to avoid TLB pressure. I imagine x86 would switch to it or something close if it weren't such a schlep.
- cesarb 6y agoAnother advantage of a 64KiB page size is that it allows for a bigger L1. The L1 is usually VIPT (for good reasons), and to prevent confusing issues with aliases, it means that its maximum size is a single page per cache way. For an 8-way cache, that means the L1 can be at most 32KiB with a 4KiB page size; with a 64KiB page size, even a 2-way L1 cache could have up to 128KiB.
- Vogtinator 6y agoopenSUSE started with 64KiB as well, but that was found to have massive memory overhead with smaller files, so it was switched back to 4KiB.
- jabl 6y agoYeah, see e.g. the Linus Torvalds rants about the "optimal" base page size. You can probably make a good case for the optimal base page size being larger than 4kB today, but probably not by very much. Maybe 16 kB or so. But then it's not a huge advantage over 4 kB which has the benefit of compatibility, so, meh..