On Wed, Apr 20, 2011 at 1:07 PM, DRAM Ninjas <[email protected]> wrote:
> 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 think it will be. As it will be a simple flag to indicate at which level it is allowed to cache. > I'll send you a patch if I get it working. > > Thanks again for your efforts. - Avadh > > > 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
