So I've done a bit of digging and apparently the Opteron does cache page walk results in the L3/L2 and in the atom block diagram in their optimization guide the DTLB is in the Memory Execution Unit which talks to the Bus Unit which has the L2 in it, so it's possible that the L2 cache holds the intermediate values, but I think it's pretty clear that L1 would never cache these values.
However, there is what I think is a bug in this code. On an L1 hit for all the page table lookups, the TLB walk latency is 0 (i.e. dcache_access returns true and then dtlb_walk() calls itself immediately). So if this happens all 4 times, then the penalty is 0 (instead of 4*L1_ACCESS_LATENCY) ... On Mon, Apr 18, 2011 at 3:00 PM, avadh patel <[email protected]> wrote: > > On Sat, Apr 16, 2011 at 10:00 AM, DRAM Ninjas <[email protected]>wrote: > >> Greetings, >> >> I'm fiddling with the tlb walk code in the atom core and I noticed that >> the addresses that are generated as part of a page table walk (root >> directory address, directory address, etc) are getting cached in the L1/L2 >> caches. I don't know if the Atom has a dedicated MMU (I would presume so), >> but would these intermediate addresses really ever get cached in the L1/L2 >> on real hardware? >> >> Good observation here. I dont know the answer to this question. Most > probably its not stored in L1/L2 caches. > > >> It seems that the time between TLB misses is long enough that you're going >> to evict these entries from the L1/L2 long before you ever re-use them >> again. I could see how caching the address of the root directory might be >> useful, but anything beyond that, it seems highly unlikely that it'll ever >> be re-used. >> >> I agree on not caching all the addresses in L1/L2 caches. There is still a > feature that needs to be implemented in new MemoryHierarchy that marks > specific requests to not be cached in L1/L2. I have filed an bug report on > github with this issue (https://github.com/avadhpatel/marss/issues/8). > > Thanks, > Avadh > > Curious to hear your thoughts. >> -Paul >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
