Messages in this thread | | | Date | Mon, 11 May 2009 15:37:58 -0700 | From | Corey Ashford <> | Subject | Re: [PATCH 3/5] perf_counter: rework ioctl()s |
| |
Paul Mackerras wrote: > Corey Ashford writes: > >> One problem that I was seeing was that disabling only the group leader didn't >> keep the group member hardware counters from continuing to run and generate >> overflows, and causing sample records to be put in the mmap buffer. > > That's very strange. Disabling the group leader should have taken the > whole group off the PMU and so none of the members should have been > able to generate any more overflows or sample records. What machines > did you see this on? > >> Was this the intention? > > Not at all. > >> For PAPI, we really need to be able to disable, at least, the sample records >> from going into the mmap buffers. Even better would be to stop the hardware >> counters from counting while disabled. > > Disabling the leader should be doing all that.
I was seeing that on Power5. On 5/6/2009, I sent along a test case that was supposed to duplicate the sequence of operations, without using PAPI, to Peter Zijlstra, cc'ing you. However, I was unable to get any signals delivered to user space with that code, so I was unable to reproduce the problem outside of the PAPI test case. I don't know why signal delivery doesn't work with that test case... I spent quite a lot of time verifying that it was doing the right thing, but could never get it to work.
I hate to ask you to debug that test case's signal handling, but that might be the fastest way to reproduce the behavior I was seeing inside of PAPI. If not, I can try to get back to the test case later this week and have another go at it, perhaps instrumenting the kernel to try to determine why its not sending signals.
- Corey
Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain cjashfor@us.ibm.com
| |