Re: Proposed systemtap access to perfmon hardware

[William Cohen <wcohen@redhat.com>]

Maynard Johnson wrote:
> Stone, Joshua I wrote:
> 
>> Maynard Johnson wrote:
>>  
>>
>>> William Cohen wrote:
>>>   
>>>
>>>> The individual start and stop operations would be allowed.
>>>>     
>>>
>>> This is not so good.  Besides the fact that it may be difficult (or
>>> impossible) to do, I don't see it being all that useful.  But then,
>>> I'm a tool developer, not a performance analyst, so I could be
>>> missing the point.
>>>   
>>
>>
>> Enabling start & stop lets you narrow the context that you want to
>> measure.  Perfmon can only give you thread level virtualization of the
>> counters.  With start & stop I can, for example, start the counters when
>> I enter sys_open and stop when I return.  Now if I want I can get a
>> microbenchmark of IPC for the sys_open call (and its callees).

The place that I see the start and stop being most useful is for the 
sampling. Start the when some event occurs and stop the sampling when 
another event occurs to get a statistic picture of what is going on in a 
certain region. It would be possible have a flag in the sample routine 
to turn on and off recording the sample. However, this would mean the 
sampling would start counting when the sampling is turned on.

For the interval measurements it may be possible to leave the counter 
counting. This would avoid messing with the performance counter state. 
In the perfmon_start_counter() mark status as running and accumulate 
count in running state. In perfmon_stop_counter() mark status as stops 
and accumulate the count in the stopped state. This could be implemented 
for the global version. It might be a bit more complicated for the per 
process version there is state information for each context and I am not 
sure about whether the additional information managing the counter 
software state could fit in the context information for a thread.

>>
>> But this also opens up possibilities for more obscure "contexts" -
>> perhaps I want to start counting when a network packet is received and
>> stop when it is delivered to the thread.  Any probepoint you can do
>> today can become a start/stop point for the counters.
>>  
>>
> Yes, I can certainly see this benefit.  It gives you PAPI-level control 
> without having to modify source code.  My concern, however, was that if 
> you have multiple counters configured, then individual control of them 
> presents an extra level of difficulty.  But, as I've been thinking about 
> this a bit more, I think this could be done if you can guarantee that 
> the operation is not preempted or interrupted.  Then, the PMU can be 
> disabled, reloaded with any changes, and then re-enabled.  Then, any 
> counters that had been running before the operation -- and that were not 
> changed by the operation -- will be reloaded with their previous count 
> and continue running from where they left off.
> 
> -Maynard
> 
>>
>> Josh

Have the probe specifying whether the performance counter is in the 
running or stopped state when setup is a good idea.

As far as when the performance counters are set up and torn down it 
seems like it would be most reasonable to set them up before the first 
probe begin action and tear them down after the last probe end action. 
This would mean for sampling would need to have it stop sampling if 
don't want any additional samples while doing the probe end action.

-Will