I do have the source code of the program, so inserting m5 pseudo instructions to dump/reset stats seems like it would work. One thing that seems difficult, is in the case of multiple threads attempting to repeatedly encounter a couple of different locks, and would continue to do so for X number of iterations.
Given such a scenario, in which repetitive dumping/reseting would result in a very large stats file, not to mention additional script parsing to add up the numbers according, it seems as though the i would have to create some new pseudo instructions that replicate the psuedo dump/reset stats insts, as well as define a similar class as to StatEvent. I was thinking that the psuedo inst that I create would record the M5 stats at the specified function calls, and then subtracting the difference between the stats collected at the start/stop times. This would give me the system stats during the period of synchronization, and then add this difference to a separate running total list that would keep track of the all stats for such synchronization events for the entire simulation. Approaching it this way seems to involve quite a few additions, changes to: 1) /src/base/stat/, 2) /src/sim/stat_control.* and possibly to /src/base/statistics.* I am unclear as to what is the best/easier approach (one that would require fewer changes), whether it being able to maintain 2 separate stats files, 1 the standard M5 stats, and the other that collects stats for the purpose i described, or hacking the existing one to get what I need. Suggestions? Malek On Tue, Aug 17, 2010 at 9:38 PM, Ali Saidi <[email protected]> wrote: > Someone else might be able to help you with m5threads, I can't. However, > assuming you have the code that you want to modify you can easily insert an > m5 pseudo instruction (see util/m5) that reset the stats or dumps them. > > Ali > > On Aug 17, 2010, at 2:37 PM, Malek Musleh wrote: > >> Hello, >> >> I was wondering if there is a way to detect instructions that are >> generated from syncronization events (e.g. spin locks generated from >> pthread mutex locks), or some manner in which I would be able to start >> stat collection after a particular core (in a Multicore simulation) >> has obtained the corresponding lock. I am not sure if simple >> checkpointing will work in this case because depending on the number >> of threads/cores in the simulation/multithreaded binary, the time at >> which I am interested most will differ. >> >> I was looking at m5threads, but I ran into some errors building it, >> but there also seems to be a lack of documentation and little recent >> work on it to make it a true alternative to pthreads. >> >> Does anybody have any suggestions? >> >> Thanks >> >> Malek >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
