On Mon, Aug 31, 2009 at 8:48 PM, Polina Dudnik<pdud...@gmail.com> wrote: > I see. It seems like it would be more appropriate to have tester test larger > requests because we are getting a false sense of correctness by running the > test. It tests the protocol logic well but not the data correctness.
It's a "false sharing" type tester, where each CPU reads and writes at a specific offset within the block and makes sure that its reads match its writes. (Ask David for the reference if you haven't read the paper...) Using bytes allows us to easily test a number of CPUs up to the number of bytes in a block. I don't see how using larger accesses would test the data any more thoroughly. The old code also supported a mode in which CPUs could do larger, random, potentially conflicting accesses, and then used a separate functional memory to check the results. Unfortunately if you don't have sequential consistency then getting the ordering right in the functional memory is very hard, so we abandoned that. It was also used when we were experimenting with an in-cache copy mechanism, but that's also been abandoned (though you'll probably still see references to that in the code). > Also, is there a maximum on the size of the m5 request? I would like to test > DMA with more realistic requests sizes, like 2048 bytes and larger. M5 itself doesn't impose a limit, but M5 caches cannot handle accesses larger than their block size, so nothing in M5 should violate that. (Strictly speaking, they can't handle accesses that cross block boundaries, so they can only handle block-sized accesses if they're block-aligned.) There are a number of places larger requests get split up into cache-block chunks; see blobHelper() in mem/port.cc and DmaPort::dmaAction() in dev/io_device.cc for a couple of examples. Steve > > Thanks, > > Polina > > On Mon, Aug 31, 2009 at 6:16 PM, Steve Reinhardt <ste...@gmail.com> wrote: >> >> Good question. Looks like historical cruft to me. I think there used >> to be a mode that tested variable-size accesses but that mode got >> ripped out. Note that access_size is log2 of the access size, so >> setting it to 0 means byte accesses. >> >> Steve >> >> On Mon, Aug 31, 2009 at 3:30 PM, Polina Dudnik<pdud...@gmail.com> wrote: >> > Hi, >> > >> > I have a question: why is it that the access_size is first calculated as >> > random() % 4 and then reset to zero before issuing the request in >> > MemTest::tick? >> > >> > Thank you. >> > >> > Polina >> > >> > _______________________________________________ >> > m5-dev mailing list >> > m5-dev@m5sim.org >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> > >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
