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？
Each page table (except perhaps the first level table) fits nicely within the page size. Perhaps that helps with the page table walker and TLB caches to remain simple.
You may want to look at the POWER9 Radix Translation (table 4-17, page 104). Such a translation supports a maximum VA size of 52 bits. For the 64KB page size, the page table sizes are 64KB, 4KB, 4KB, 256B. This corresponds to the VA division of 13,9,9,5,16. If one looks at the other supported page sizes, one finds that POWER9 keeps the table sizes constant (except perhaps the last level table), even when the page sizes change.
I find that the armv8 scheme keeps the software simple to some extent. Since the page size and the table size are the same, the memory management of the page tables is simplified. With POWER9, one needs a heap manager to maintain pools of 64KB, 4KB and 256B allocations in order to satisfy allocation/deallocation of mmu tables. With the MMU turned on, this creates a chicken-and-egg problem - the heap manager is dependent upon the MMU in the usual case of running with the MMU on, and the MMU is in turn dependent upon the heap manager for allocation/deallocation of tables. With the armv8 scheme, the management of such dependencies is, IMHO, somewhat simpler, because one can work without the heap manager and rely just on the MMU and a physical page allocator to setup the page tables. For a general purpose OS like Linux, this difference may not matter much.
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.