Korey, that's awesome. If you've done it already, then by all means, let's see it on the review board.
And Steve, you are right, Ruby does not do stats per context, though recently a set of my pushes made it possible to even pass that information to Ruby. Nothing in the tree takes advantage of it now, but at least the infrastructure for passing the info is there. Lisa On Wed, Apr 20, 2011 at 10:07 AM, Steve Reinhardt <ste...@gmail.com> wrote: > I'd definitely like to see us focus our efforts on Ruby. That said, > if you've got the code working, there's no reason not to use it. > Also, I'm guessing that a similar problem will exist in Ruby if the > Ruby cache ever extends its stats to be per context... I expect the > only reason Ruby doesn't have this problem is that the stats are not > segregated that way. Someone speak up if I'm wrong about that please. > > Steve > > On Wed, Apr 20, 2011 at 10:04 AM, Korey Sewell <ksew...@umich.edu> wrote: > >> I think Lisa's "pythonic fix" is the one where we use the _numCpus > >> value that's calculated entirely in python (including the +1 offset in > >> FS mode) and don't attempt the automatic C++ technique that Korey > >> proposed. > > > > Hey guys, > > with the new Ruby memory system coming, how much of the classic memory > > system support (or features) are we still going to be adding on? > > > > I ask because I was curious about this last night and wrote a good chunk > of > > the code for the "automatic C++ technique" (actually wasnt too hard to > > write). The problem Lisa posed of hierarchy confusion I approached and > just > > now thought how to truly solve it. Basically, instead of passing a > "sharer > > count" from upstream caches, pass a set of sharers and then you keep > adding > > to that set as you combine results from multiple ports on a bus. I also > > coded it so that you only do this "auto-technique" if an original > parameter > > wasn't set (so Lisa's way would still work). > > > > So I guess what I am asking is does anyone care about that feature of > > automatically determining the sharers OR since Ruby will be the preferred > > memory system that any feature (or complexity) I add to this would be > > unnecessary in the big picture? > > > > If it's the latter, I'm OK with that, I can just post what I have to the > > reviewboard at some point for someone who might care in the future (its > at > > the back of a long patchqueue right now). > > > > If people do care or think it would be a cool add-on, I can wait until > Lisa > > does her 1st pass post of this and then at that point match the variable > > names and post my "auto-solution". > > > > -- > > - Korey > > _______________________________________________ > > 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
