It'd be good for Lisa to chime in here to comment on the exact meaning of _numCpus and how that value is intended to be set.
If you dont care about threads per CPU (and just the raw "# of CPUs" value), then I'd defer to Lisa for figuring out what the right vector lengths are so that they are consistent :) However, since "_numCpus" seems to be a parameter given to the BaseCache, then the burden is on the script writer to figure out how many CPUs that a cache is sharing rather than automatically going through the cache hierarchy and figuring it out. That seems like the "ultimately right" thing to do. Lastly, I'm not sure how maxThreadsPerCPU plays into this but if you needed to get that threads value on a perCPU basis, then the suggested CPU search method would also work well. On Tue, Apr 19, 2011 at 11:35 AM, Steve Reinhardt <[email protected]> wrote: > Lisa should verify, but I think that's what _numCpus is. > > On Tue, Apr 19, 2011 at 8:01 AM, Korey Sewell <[email protected]> wrote: >> Hey Steve, >> I dont disagree with your solution (at least in the interim), but >> wouldn't the right solution be to have the actual CPUs pass how many >> hardware threads is has to the caches? >> >> The actual "regStats" happens after all the CPUs are instantiated and >> ports are connected (right?), so it would seem that since different >> CPUs can have a different amount of threads per CPU, that the caches >> should just use the port interface to ask "how many threads?" . Then, >> the caches down the hierarchy would just sum those thread counts up >> for each of their Stat vectors. >> >> I imagine a similar method to how the "M5 classic" figured out address >> ranges and snoop ports would work fine. >> >> Do people think that's fine or am I missing the point here? >> >> On Tue, Apr 19, 2011 at 10:42 AM, Steve Reinhardt <[email protected]> wrote: >>> Looks like it's Lisa's fault ;-) >>> >>> http://repo.m5sim.org/m5/diff/ab05e20dc4a7/src/mem/cache/base.cc >>> >>> I think Nate's point is that all the stats vector lengths should be >>> changed to _numCpus or _numCpus+1 instead of maxThreadsPerCpu to be >>> consistent. >>> >>> We should also either (1) always do _numCpus+1 even though the extra >>> "device" slot is unnecessary for SE mode or (2) have a single #ifdef >>> to set a local var to one or the other and use that consistently >>> rather than having #ifdefs all over the place. I'd lean toward #2 >>> just to keep the output a little cleaner in SE mode. >>> >>> Does that make sense, Lisa? >>> >>> Steve >>> >>> On Mon, Apr 18, 2011 at 3:58 PM, nathan binkert <[email protected]> wrote: >>>> Yes, but all arithmetic between vectors is elementwise, so they need >>>> to be the same length if used in a formula. Total miss latency needs >>>> to have the same vector length as total misses. >>>> >>>> Nate >>>> >>>> On Mon, Apr 18, 2011 at 2:09 PM, Lisa Hsu <[email protected]> wrote: >>>>> I'm not sure I understand what the problem is either. Can different >>>>> VectorStats not have different lengths? >>>>> >>>>> Lisa >>>>> >>>>> On Mon, Apr 18, 2011 at 11:43 AM, Gabriel Michael Black < >>>>> [email protected]> wrote: >>>>> >>>>>> My first reaction is "let's fix it", but I don't really understand the >>>>>> problem or the impact of changing things. Anything serious? >>>>>> >>>>>> Gabe >>>>>> >>>>>> >>>>>> Quoting nathan binkert <[email protected]>: >>>>>> >>>>>> I'm trying to get my python stats stuff committed and I found a bug in >>>>>>> the classic cache stats. Look in src/mem/cache/base.cc. The >>>>>>> VectorStats have several different lengths "_numCpus + 1", "_numCpus", >>>>>>> or "maxThreadsPerCPU". >>>>>>> >>>>>>> The fact that this works in the current stats package is lucky. I can >>>>>>> be bug compatible, but I think we should fix this instead. >>>>>>> >>>>>>> Nate >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> - Korey >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > -- - Korey _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
