perf_counter: resetting a event counter

perf_counter: resetting a event counter

[Corey Ashford]

Hi,

In implementing the PAPI_reset function, whose purpose is to reset all 
of the counters in an event set, I found that [it appears] there is no 
straight-forward way to implement this function using "Performance 
Couunters for Linux".  My current implementation just closes the 
counters and reopens them again.  This is not a elegant solution, nor is 
the other alternative that occurred to me: maintain a "virtual" counter 
in user space, maintained using a base count, which is subtracted off of 
the current perf_counter value of a particular counter.

Is there a way that I missed to reset an event counter?  If not, I'd 
like to request that a new ioctl command be added to support this ability.

Thanks for your consideration,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@us.ibm.com

Re: perf_counter: resetting a event counter

[Ingo Molnar]

* Corey Ashford <cjashfor@linux.vnet.ibm.com> wrote:

> Hi,
>
> In implementing the PAPI_reset function, whose purpose is to reset 
> all of the counters in an event set, I found that [it appears] 
> there is no straight-forward way to implement this function using 
> "Performance Couunters for Linux".  My current implementation just 
> closes the counters and reopens them again.  This is not a elegant 
> solution, nor is the other alternative that occurred to me: 
> maintain a "virtual" counter in user space, maintained using a 
> base count, which is subtracted off of the current perf_counter 
> value of a particular counter.
>
> Is there a way that I missed to reset an event counter?  If not, 
> I'd like to request that a new ioctl command be added to support 
> this ability.

We already have such ioctl actions:

        case PERF_COUNTER_IOC_ENABLE:
        case PERF_COUNTER_IOC_DISABLE:
        case PERF_COUNTER_IOC_REFRESH:

It would be a pretty natural addition to also have a reset method 
there. Would you like to take a stab at it and send a patch? A 
first-level approximation would be to do something like:

	perf_counter_disable(counter);
	atomic64_set(&counter->count, 0);
	perf_counter_enable(counter);

btw, the reset code should probably take the counter->mutex lock as 
well, because parallel resets done from multiple contexts are 
otherwise not well-defined.

	Ingo

Re: perf_counter: resetting a event counter

[Peter Zijlstra]

On Tue, 2009-05-05 at 08:52 +0200, Ingo Molnar wrote:
> * Corey Ashford <cjashfor@linux.vnet.ibm.com> wrote:
> 
> > Hi,
> >
> > In implementing the PAPI_reset function, whose purpose is to reset 
> > all of the counters in an event set, I found that [it appears] 
> > there is no straight-forward way to implement this function using 
> > "Performance Couunters for Linux".  My current implementation just 
> > closes the counters and reopens them again.  This is not a elegant 
> > solution, nor is the other alternative that occurred to me: 
> > maintain a "virtual" counter in user space, maintained using a 
> > base count, which is subtracted off of the current perf_counter 
> > value of a particular counter.
> >
> > Is there a way that I missed to reset an event counter?  If not, 
> > I'd like to request that a new ioctl command be added to support 
> > this ability.
> 
> We already have such ioctl actions:
> 
>         case PERF_COUNTER_IOC_ENABLE:
>         case PERF_COUNTER_IOC_DISABLE:
>         case PERF_COUNTER_IOC_REFRESH:
> 
> It would be a pretty natural addition to also have a reset method 
> there. Would you like to take a stab at it and send a patch? A 
> first-level approximation would be to do something like:
> 
> 	perf_counter_disable(counter);
> 	atomic64_set(&counter->count, 0);
> 	perf_counter_enable(counter);
> 
> btw, the reset code should probably take the counter->mutex lock as 
> well, because parallel resets done from multiple contexts are 
> otherwise not well-defined.

I would suggest simply bailing when the counter is active when trying to
reset if anything.

A plain: atomic64_set(&counter->count, 0), sounds attractive too.

The trouble with putting in those disable/enable calls is that you
cannot use the ioctl on an already disabled call, since it will
immediately enable it. Also, using it on an active counter is racy in
nature so the disable/enable cycle (or the proposed mutex) doesn't buy
you anything.

Re: perf_counter: resetting a event counter

[Ingo Molnar]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> On Tue, 2009-05-05 at 08:52 +0200, Ingo Molnar wrote:
> > * Corey Ashford <cjashfor@linux.vnet.ibm.com> wrote:
> > 
> > > Hi,
> > >
> > > In implementing the PAPI_reset function, whose purpose is to reset 
> > > all of the counters in an event set, I found that [it appears] 
> > > there is no straight-forward way to implement this function using 
> > > "Performance Couunters for Linux".  My current implementation just 
> > > closes the counters and reopens them again.  This is not a elegant 
> > > solution, nor is the other alternative that occurred to me: 
> > > maintain a "virtual" counter in user space, maintained using a 
> > > base count, which is subtracted off of the current perf_counter 
> > > value of a particular counter.
> > >
> > > Is there a way that I missed to reset an event counter?  If not, 
> > > I'd like to request that a new ioctl command be added to support 
> > > this ability.
> > 
> > We already have such ioctl actions:
> > 
> >         case PERF_COUNTER_IOC_ENABLE:
> >         case PERF_COUNTER_IOC_DISABLE:
> >         case PERF_COUNTER_IOC_REFRESH:
> > 
> > It would be a pretty natural addition to also have a reset method 
> > there. Would you like to take a stab at it and send a patch? A 
> > first-level approximation would be to do something like:
> > 
> > 	perf_counter_disable(counter);
> > 	atomic64_set(&counter->count, 0);
> > 	perf_counter_enable(counter);
> > 
> > btw, the reset code should probably take the counter->mutex lock as 
> > well, because parallel resets done from multiple contexts are 
> > otherwise not well-defined.
> 
> I would suggest simply bailing when the counter is active when 
> trying to reset if anything.
> 
> A plain: atomic64_set(&counter->count, 0), sounds attractive too.
> 
> The trouble with putting in those disable/enable calls is that you 
> cannot use the ioctl on an already disabled call, since it will 
> immediately enable it. Also, using it on an active counter is racy 
> in nature so the disable/enable cycle (or the proposed mutex) 
> doesn't buy you anything.

Yes, it all seems a bit racy - but straightforward.

I dont think we should restrict the ioctl to disabled state alone - 
we should disable it if it's not disabled - reset the counter - then 
re-enable-it if it was enabled before.

Btw., hw_counter->prev_counter needs to be reset too (if it's a hw 
counter not a sw counter), right?

	Ingo