Derek's comment about the cache set bug points out that we've probably been encountering many of the same bugs and I need to do a better job of pushing out and sharing my bug fixes sooner. Over the past several weeks, I've been adding full system support to ruby, resurrecting the old MOESI_hammer protocol and validating the sparse memory support. I was delaying sending out my patches until all that work is complete, but I now realize that others could benefit from my patches in the near-term.
I have 31 patches that I would like everyone to review before I push them. Let me know if you have any questions. Thanks, Brad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Derek Hower Sent: Thursday, November 05, 2009 1:29 PM To: M5 Developer List Subject: Re: [m5-dev] memtest-ruby might not belong in quick I have several patches for Ruby in my repository that speed it up, including one rather important bug fix that corrects the way the cache memory calculates the number of sets to construct. I'll try to push those in on or around Nov. 17. -Derek On Thu, Nov 5, 2009 at 10:46 AM, Steve Reinhardt <[email protected]> wrote: > > > On Sat, Oct 31, 2009 at 12:50 PM, nathan binkert <[email protected]> wrote: >> >> > I'm currently waiting for memtest-ruby to finish running, and looking at >> > the stats that's going to take about 55 minutes all together. That >> > doesn't qualify as quick to me, so maybe it shouldn't be in the quick >> > regressions? >> >> We could probably have two different memtests. One quick and one long >> and just differ the number of requests they do. >> >> I really need to find the time to improve our tests... > > I played with this a little bit... right now it's a single test (50.memtest) > just run on two different configs (m5 "classic" and Ruby), so they share the > parameter of how many loads to run for. There's no easy, clean way to tell > from the test.py file which version you're running (it's part of the > run-time config, not a compile-time flag), so it's not obvious to me how to > fix it in place. As Nate says, splitting it out into a completely different > test would be one way to do it. The solution I'd prefer is for someone to > make Ruby run as fast as the native M5 memory system :-). > > Steve > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
