> On June 3, 2013, 8:16 p.m., Ali Saidi wrote: > > src/cpu/decode_cache.hh, line 129 > > <http://reviews.gem5.org/r/1892/diff/1/?file=35743#file35743line129> > > > > is this appreciably faster than rand() or better yet the Random class > > in base which is just using a mersenne twister? > > Andreas Sandberg wrote: > I agree that it is a bit (actually very) ugly to have the random number > generator there. I didn't want to use the Mersenne twister for performance > reasons, but that might have been a premature optimization since this code > shouldn't be executed often anyway. I'll replace it with call to the MT > implementation unless someone else has a better idea.
I hope this isn't executed often either... should we have a stat that counts the number of times it happens, or print a warning? The stat is likely to be ignored but would be less intrusive. Back on topic: if performance is an issue, one option would be to avoid calling the RNG on every page. For example, if you precalculate that you're going to get rid of 1/N of the pages in the cache, then call the RNG once to pick a number 0 <= s < N, skip s pages, then delete every Nth page after that. The pseudo-randomness of the order of pages when iterating over the map should provide some protection against pathological behavior. It might help if N is an odd prime, like 3 or 5. Popping up a level, if the main driver of this is dealing with ASR, then we might want to consider having a physically indexed page cache, as a sort of "backing store" for the virtually indexed cache(s). This should prevent the problem from arising in the first place and make disabling ASR unnecessary. I think this patch should go in regardless, but if we want to make ASR work OK as opposed to just less pathologically, we should think about taking this second step as well. Also, if we fix the one situation that we know is likely to trigger this replacement, then handling the replacement efficiently becomes even less important. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1892/#review4381 ----------------------------------------------------------- On June 3, 2013, 5:36 a.m., Andreas Sandberg wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1892/ > ----------------------------------------------------------- > > (Updated June 3, 2013, 5:36 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9739:245243cf497d > --------------------------- > cpu: Limit the size of the decode cache > > The decode cache can in some cases grow really large, which can even > prevent some systems from booting. This changeset adds a the ability > to limit the size of the decode cache and randomly prune a fraction of > the cache once it reaches its upper limit. The default behavior on > most architectures is now to allow 4k pages in the cache and prune 50% > once this limit is reached. > > > Diffs > ----- > > src/arch/generic/decode_cache.hh 304a37519d11 > src/arch/x86/decoder.hh 304a37519d11 > src/cpu/decode_cache.hh 304a37519d11 > > Diff: http://reviews.gem5.org/r/1892/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Sandberg > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
