as we can see from arm programming guide, armv8 level1 level2 page table size for different granule is the size of granule. for example, for 4K granule level1 level2 table have 512 entries, and each entry occupies 8 byte, so the size is 512 * 8 = 4K。
so， my question is why the page table size of level1 level2 themselves are the size of granule size? is it a micro-architecture trade off or just empirical value？
a.surati, thanks for your replay.
so, in a word, the dynamically allocated page table memory comes from page table heap, which is managed tightly couplled with granule, am i right?
The heap has no relation with the granule. I was merely comparing two architectures which take contradictory approaches to selecting the page table sizes, and commenting on how armv8 policy might result in simpler software.
Unknown said:my question is why the page table size of level1 level2 themselves are the size of granule size?
Because it is so, by definition. The section "D5.2.4 Memory translation granule size" says that the granule size defines both the "The maximum size of a single translation table." and "The memory page size". Since the "granule size" defines the "page table size", the page table sizes are the same as, or smaller than, the granule size.
The same section also hints at the advantages of utilizing a larger granule size - less number of translation levels, less number of bits that need translation, reduced load on TLB cache.