Victor, Your patch was applied with a tiny change to use for_each_bit(). Please try it again. Thanks.
On Thu, May 21, 2009 at 1:20 AM, victor jimenez <betaband...@gmail.com> wrote: > Hello, > > the program I was using when I discovered the problem is pretty > complex, but I will try to see if I can make a small test program > which can reproduce the error. > > In the meanwhile, I have created a very small patch which can fix the > problem. I am attaching it. It tries to emulate the Intel behaviour > when stopping (i.e., PMDs are saved). > > Do you think it is OK? > > Regards, > Victor > > On Wed, May 20, 2009 at 7:44 PM, Corey J Ashford <cjash...@us.ibm.com> wrote: >> 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 >> >> > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > perfmon2-devel mailing list > perfmon2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel > > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
