On Tue, 25 Nov 2014, Beckmann, Brad wrote:
Thanks Nilay for the prompt reply. An example of a protocol specific statistic would be if say in a region coherence protocol [Power et al.], I was profiling the latencies of downgrade request-acks and I wanted to do that for the cross-product of requestor and request type. That is just one example, there are a million different possible statistics one could imagine wanting to collect. The specific example isn't important, the important part is we need any easy way to add protocol specific statistic processing. In other words, I want to collect data that doesn't neatly match a current gem5 statistic type and instead requires some sort of C++ customization before being added to a static data type.
I think you are using a map or vector of some type. I would probably make SLICC understand what those types are. If you don't want to go that way, then you will have to do something similar to the earlier setup. Prototype a function in one of the .sm files, then define it say in RubySlicc_Util.hh and add the corresponding variable in the Profiler class.
I'm not advocating for the prior solution. I completely agree going through the RubySlicc_Profile files was not great, but it is better than going through the AbstractController. At least the RubySlicc_Profile files were only collecting profile features. The AbstractController is growing into a beast. Perhaps what I'm looking for is an AbstractProfiler class that we can offload the current profiling work done by the AbstractController.
Going through the abstract controller can be another way. I am actually not worried about the size of the class, unless you think that some function or data member is unecessary. We can define a class with in the AbstractController if you are worried about the profiling variables. If I am counting correctly, there are just three of them right now.
I like the work you've done to collate statistics from independent object instantiations to a common set of data structures. We need to work on how those data structures are printed out, but your overall approach seems great. It seems the real problem we have now is that the generated collateStats functions directly cast to the AbstractController, thus all the stat interface functions need to be in the AbstractController. Instead, we to generate a protocol specific controller profiler that perhaps inherits from a to-be-determined AbstractProfiler class.
The Profiler class still exists. You can still define a globally visible function that calls on the profiler to store some statistic. This is what use to happen before. The only other way I can think of is to make SLICC understand the different data structures we want to work with and use them in .sm files.
-- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
