Re: [PATCH 3/5] perf_counter: rework ioctl()s

[Corey Ashford <cjashfor@linux.vnet.ibm.com>]

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