victor jimenez <betaband...@gmail.com> wrote on 05/20/2009 09:24:43 AM:
> Hello, > > I did more tests and I think I found the reason why it is not working. > I am attaching a log with the debug information. The log shows > information between a call to sys_pfm_start() and sys_pfm_stop(), plus > a following call to sys_pfm_read_pmds(). > > In file perfmon/perfmon_ctxsw.c:242, pfm_save_pmds() is called > depending on the value returned by pfm_arch_ctxswout_thread(). This > second function returns the value returned by pfm_arch_is_active(). > pfm_arch_is_active() returns 1 when the process is being monitor > (after calling pfm_start) and 0 if the process is not (after calling > pfm_stop). > > The problem is that using only pfm_arch_is_active() to determine > whether we should save the PMDs or not is not enough. When pfm_stop() > is called the PMDs are not being saved in the powerpc implementation > of perfmon2 (they are saved in the x86 implementation). Therefore, if > after calling pfm_stop() a the process is switched out > pfm_arch_is_active() will return 0 (because the process is not being > monitored; we already call pfm_stop()). This will cause that the PMDs > are not saved at the context switch time and, thus the wrong ones will > be restored later. > > All this can be seen in the attached log. At line 103 sys_pfm_stop() > is called. At line 112 sys_pfm_read_pmds() is called. For instance, > the value for counter 5 (#instructions) is 1218670811. Then a context > switch comes, but at line 128 we can see how need_save_pmds is 0 so > the PMDs are not saved. Next time they are restored, at line 135 (for > counter 5) the value is 1207034044. This value is the value which was > saved before at line 83. > > I hope this can help to find an solution. It definitely does! I haven't looked at this code for awhile, so I'm working on getting back up to speed. I see the exact issue you are talking about and how the Power implementation is different from the x86 implementation. The structure of the calls is different: x86 has a stop_save per-pmu-type call, whereas Power has a single pfm_stop_active call. You can see that the comments in the Power code originally came from the x86 implementation, because it still refers to "stop_save()" in pfm_arch_stop, but obviously we took a slightly different tack after the two diverged. I think the fix needs to go in pfm_stop_active, though, since that is the equivalent spot in the Power implementation. I will try out a fix and see how it goes. Do you have a test case I could try that reproduces this? If not, I'm sure I could come up with one, but a ready-made test case would save me some time. Regards, - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain cjash...@us.ibm.com ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
