Hey guys,
I've also recently run across situations in which I would have liked to
collect stats within specific coherence controllers. It doesn't address
Brad's immediate need, but I'd like to throw out the idea of adding a
statistics interface to the SLICC compiler. I don't expect it would be that
difficult to add a statistics identifier (like 'structure', 'action', or
'transition') that behaves like a SLICC type specifier, but actually
generates statistics code in the generated controller.
For example:
statistic(stat_dngrdReqAck, type="Vector", desc="",
init="machineCount(MachineType:L2Cache)");
Then in the appropriate coherence action:
stat_dngrdReqAck[ctrl_id] := stat_dgrdReqAck[ctrl_id] + 1;
It might be a bit of work, but it should be straightforward to generate
the appropriate gem5 stats declaration and regStats() function within the
controllers. This organization would offer controller-specific stats, so as
expressive as we could want. The existing stats could be left as is, so the
protocol dev wouldn't need to collect event counts manually, just the
specific things for which they may be looking.
Joel
On Mon, Nov 24, 2014 at 8:49 PM, Nilay Vaish via gem5-dev <[email protected]
> wrote:
> 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
>
--
Joel Hestness
PhD Candidate, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
