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'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. 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. Does that make sense to you? Brad -----Original Message----- From: Nilay Vaish [mailto:[email protected]] Sent: Monday, November 24, 2014 3:22 PM To: Beckmann, Brad Cc: gem5 Developer List ([email protected]) Subject: Re: Protocol Specific Profiling On Mon, 24 Nov 2014, Beckmann, Brad wrote: > Hi Nilay, > > On July 24, 2013 you removed the RubySlice_Profiler.sm, > RubySlicc_Profiler_interface.cc and RubySlicc_Profiler_interface.hh > files. See changeset 9771:57aac1719f86. By removing those files, you > removed the ability to provide protocol specific profiling. Your I think you need to define what you mean by protocol specific profiling. The .sm file just contained some function prototypes. The actual definitions were calling on the RubySystem to get the RubyProfiler, both of which can be instantiated only once. > comment seems to suggest that you expect that all profile functions > called by the .sm files to use functions defined in AbstractController. > Is that correct? That solution doesn't seem very scalable and it will > lead to a very large AbstractController definition (I'm quite > surprised how much that file has grown in the past two years...20+ > modifications). If you need a new statistic, it should be defined in the .sm file for the controller that needs the statistic. That would be protocol specific. Defining everything in a single place is not protocol specific. > > Do you see a better way to support protocol specific profiling? We > could add back in the RubySlice_Profiler.sm, > RubySlicc_Profiler_interface.cc and RubySlicc_Profiler_interface.hh > files, but I understand the benefit to have the functions be defined > on a per machine basis. > If you want the previous setup back, you can bring it back. Otherwise you can add code to RubySlicc_Util.hh in fashion similar to RubySlicc_Profiler.hh. -- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
