问题
I have the following specifications of an ARM based SoC:
- L1 Data cache = 32 KB, 64 B/line, 2-WAY, LRU
- L2 Cache = 1 MB, 64 B/line, 16-WAY
- L1 Data TLB (for loads): 32 entries, fully associative
- L2 Data TLB: 512 entries, 4-WAY
- PDE Cache: 16 entries (one entry per 1 MB of virtual space)
And I wonder what is the PDE cache? I guess it's something similar to TLB, but I'm not sure.
Answer
It seems that PDE (Page Directory Entry) is Intermediate table walk cache which indeed can be implemented separately from TLB.
The Cortex-A15 MPCore processor implements dedicated caches that store intermediate levels of translation table entries as part of a table walk.
回答1:
That's interesting. ARM does not name the existence of this PDE cache in Cortex-A15, Cortex-A57 documentations and ARMv7 and ARMv8 programming guides.
PDE generally stands for Page Directory Entry so this may be a dedicated cache to store these entries and write the TTBR register when doing an address translation.
ARM has some "intermediate table walk caches" that are associated with an ASID field (address space identifier) and VMID field (virtual machine identifier) so it seems like PDE cache and intermediate table walk cache are related. In the documentation, "intermediate table walk caches" store intermediate levels of translation table entries ... so this may well be the page directory entries.
回答2:
A PDE ("Page Directory Entry") is x86 architecture terminology for a top level* page table entry - the equivalent of a "first-level descriptor" in ARM VMSA terms.
Assuming this is the source of the data in the question, it's presumably referring to Cortex-A15's "intermediate table walk cache", which is not entirely appropriate since that can actually cache any level of translation.
* in IA-32 at least - 64-bit mode has levels above this
回答3:
A TLB caches full translations, it doesn't reflect a coherent part of the memory per-se (although not being coherent, it may cause loss of coherency in case the page map changes, so SW must enforce coherency explicitly through flushing).
However, the pagemap itself does reside in memory, and as such - every part of it may also be cached, whether in the general purpose cache hierarchy, or within special dedicated caches such as a PDE cache. This is implementation specific, different CPUs may decide differently how to do that.
An access hitting the TLB (in any of its levels) won't need that data, but a TLB miss will trigger a pagewalk which will issue memory reads from the pagemap - these reads may hit in the caches if they include the pagemap data, instead of having to go all the way to memory.
Since a pagewalk is a long, serialized, critical chain of accesses (even more so if you have virtualization), you can imagine how important it is to optimize the latency of these accesses by caching them. Therefore, a dedicated cache to any of the pagemap levels, which would help them compete with the normal data lines (that are much more frequently thrashing the cache), is often very useful for performance
来源：https://stackoverflow.com/questions/26945448/what-is-pde-cache