> On Feb. 6, 2015, 9:10 a.m., Steve Reinhardt wrote: > > So would this replace memtest.py? If so, then factoring out the common > > code would not be an issue. If not, why not? > > Andreas Hansson wrote: > The two are complementary: > > memtest.py uses MemTest and only tests false sharing, with some progress > detection built in > > memcheck.py uses TrafficGen and MemCheck and tests actual sharing and > prefetching, and has a mix of random and strided access patterns > > > Steve Reinhardt wrote: > But do you expect that there are errors that memtest.py would find that > memcheck.py would not, even allowing for some tweaking of the TrafficGen > access patterns? The overhead of not just maintaining but also running two > different memory testers seems pretty high, so even if they have > complementary approaches, it seems worthwhile only if they have significant > non-overlap in their coverage of the memory system state/protocol transition > space. > > Andreas Hansson wrote: > I do believe that they both fill a purpose at the moment. > > memtest.py has very little state, and can work on a much larger scale > (100's of testers with 10's of cache levels), I have run some 100 trillion > cycles with this (once the message-dependent deadlocks are fixes) > > memcheck.py relies on the MemCheck tracking of what the allowed read > values are, and the state tracking does not scale very well at this point. I > believe we can do some more aggressive pruning (and this is planned work), > but even running a few billion cycles is currently challenging > > Long term the memcheck is probably all we need
Fair enough, makes sense. Seems like in the long run memcheck.py could be generalized to plug in MemTest objects in the place of TrafficGen objects, then making the MemCheck objects optional, thus subsuming memtest.py more directly. I'm fine with leaving that to future work though. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2626/#review5855 ----------------------------------------------------------- On Feb. 3, 2015, 11:57 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2626/ > ----------------------------------------------------------- > > (Updated Feb. 3, 2015, 11:57 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10692:f0a93f672561 > --------------------------- > config: Add memcheck stress test > > This is a rather unfortunate copy of the memtest.py example script, > that actually stresses the system with true sharing as opposed to the > false sharing of the MemTest. To do so it uses TrafficGen instances to > generate the reads/writes, and MemCheckerMonitor combined with the > MemChecker to check the validity of the read/written values. > > As a bonus, this script also enables the addition of prefetchers, and > the traffic is created to have a mix of random addresses and linear > strides. We use the TaggedPrefetcher since the packets do not have a > request with a PC. > > At the moment the code is almost identical to the memtest.py script, > and no effort has been made to factor out the construction of the > tree. The challenge is that the instantiation and connection of the > testers and monitors is done as part of the tree building. > > > Diffs > ----- > > configs/example/memcheck.py PRE-CREATION > > Diff: http://reviews.gem5.org/r/2626/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
