It occurred to me that this behavior could be related to the thread we had before about overlapping page table walks for the same page... Gabe and I had already agreed that if you have a TLB miss to an address that lies within the same page (at the minimum page size) as an ongoing walk, you really should not fire off another walk, but that's what we currently do. Adding that suppression of redundant walks wouldn't directly fix this problem, but it probably would mitigate the effects.
As far as the problem itself: even if the TLB itself has no bandwidth limit, there should definitely be a limit on the number of concurrent page walks, probably something in the low single digits. With a hardware table walker, there is hardware state associated with each ongoing walk, and the number of copies of this state to allow concurrent walks is very limited. Steve On Sun, May 20, 2012 at 7:36 AM, Ali Saidi <sa...@umich.edu> wrote: > Yes, there isn't any back pressure here and there probably/maybeshould be. > The reason we've got away with it before is that normally the pressure > comes from the cpu itself. The number of outstanding translations is > limited by the size of the LSQ. That is why I find this to be strange. > there is some code that is executing and must be mis-predicting constantly > to fill up the tlb with translations and the get squashed, only to do the > exact same thing again. It seems like the second time through the branch > should be correct. The fastest way forward is probably to add the ability > to squash all pending tlb translations (except maybe the one that is > currently going on) as you through those instructions out of the lsq on a > mispredict. Make sense? > > Ali > > > > > > On May 15, 2012, at 8:48 AM, Gabe Black wrote: > > > There's a limit on the size of the TLB itself, but there may not be a > limit on the number of translations it's doing at one time. I suspect > that's an important part of the problem. > > > > Gabe > > > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
