Also, could someone explain how the idleCycle count compares to the kernel stat "mode_ticks_idle"? Obviously, one is in cycles and the other one is in ticks, but they seem to be capturing two different behaviors.
Thanks, Brad From: [email protected] [mailto:[email protected]] On Behalf Of Steve Reinhardt Sent: Monday, February 16, 2009 4:34 PM To: M5 Developer List Subject: Re: [m5-dev] a couple of funny things about O3 stats OK, the kernel stats fix is easy enough. As far as idleCycles, I have another question: in O3, this appears to be measuring the number of cycles the model is not ticked, regardless of whether it's due to explicit idling (e.g., due to the quiesce instruction in Alpha) or due to a general pipeline stall (e.g., due to a long-latency cache miss filling the ROB). Is this correct? The idleFraction/notIdleFraction statistics used by the other CPU models are only affected by calls to suspendContext and activateContext, which means they really only track explicit idling. That's really the measure I'm looking for at this point in time, but it appears that the O3 model doesn't directly provide that. Does anyone know of a way to get that info from the O3 model? Thanks, Steve 2009/2/16 Kevin Lim <[email protected]> Regarding the kernel stats, I had assumed that in taking over for another CPU, you'd still want to keep the same kernel statistics because you're still running the same system. I didn't realize that the stats would be registered to each CPU and thus create fairly confusing output. Unless Nate has something to add I think it's fairly safe to remove the transferring upon switch over. Regarding the idle cycles, it sounds like the proper solution would be the last two you mentioned. Kevin Steve Reinhardt wrote: I've discovered a couple of stats oddities that should be fixed, but I'm not sure what the best approach is. They both have to do with looking at the stats for an O3 CPU after an FS run in which we restore from a checkpoint to a SimpleCPU and then switch to an O3 CPU. Specifically I was trying to figure out why, when comparing two runs where in one case the CPU should have had much more idle time than the other, the stats seemed to indicate that there was very little idle time in either case. First, in O3ThreadContext<Impl>::takeOverFrom(), the kernelStats pointer of the old context overwrites the kernelStats pointer of the new context, with the comment "Transfer kernel stats from one CPU to the other." The problem is that the final output is confusing... all of the kernel stats are associated with the SimpleCPU, and the kernel stats values of the O3 CPU (which got registered when the O3 object was created, before the call to takeOverFrom()) are all zero. I was specifically looking at the number of quiesce instructions executed, and the stats told me that the SimpleCPU executed a few hundred in the small window it was executing while the O3 CPU executed none. The easy solution here is just to whack the kernelStats assignment in takeOverFrom(), but I wanted to know if there was a good reason for doing this that I'm missing. Also, this same assignment appears in most (all?) of the takeOverFrom() functions of the other CPU models, so if we get rid of it at all we should get rid of it everwhere. Second, the real culprit turned out to be the way that idle cycles are accounted for in O3. In wakeCPU(), both the numCycles and idleCycles stats are updated with the number of cycles the CPU has been idling. (When the CPU is not idling, numCycles is incremented each cycle and of course idleCycles is not updated at all.) In general this is OK, but when the simulation ends while the CPU is still idling, then there is a potentially substantial number of cycles that don't get added in to either counter. One way to fix this is to call wakeCPU() just before terminating the simulation, but that seems very hackish and prone to unwanted side effects. Another way would be to have some "cleanup" function that SimObjects can register (much like init()) that gets called before stats are dumped, and then in the O3 model we could use this hook to update these stats before they get dumped. A final way would be to dump the idleCycles and replace it with a Stat::Average idleFraction statistic like we use in the other CPUmodels... this would also have the nice side effect of making the statistics more consistent across the CPU models, but it would not solve the problem with numCycles. Thoughts? Steve ________________________________ _______________________________________________ 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
