So I think the ability to have the table walk addresses skip the cache is important enough to us that I'm going to implement it. I think it will be relatively straight forward (I hope).
I'll send you a patch if I get it working. On Tue, Apr 19, 2011 at 5:56 PM, DRAM Ninjas <[email protected]> wrote: > 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
