>> I just started working with oprofile (actually working on PowerPC
>> performance counter support for Power4 variants including GP/UL) and was
>> wondering if there was ever any discussion of extending oprofile to sample
>> hardware performance counters on context switches? (first step towards
>> recording performance counters per process more accurately).
>humm, oprofile is designed as a system-wide profiler, this is a bit
>agaisnt this design and afaics you can't use both interrupt on overflow
>and count event by task.

I'm fine with the system-wide aspect of oprofile, I just want to be able to
accurately charge performance counters to every task instead of getting
sampled results.  We are using these results for validation of simulation and
want to try and limit noise as much as possible - each task will have its own
set of performance counters which will be swapped in/out with the rest of their
context.  Interrupts get their own buckets for performance counters.

I don't see how this conflicts with using overflow interrupts, but I've just
started looking into stuff.

>> On a separate note, the architectures I'm targeting only use performance
>> counter group  (you select all 8 counters as a group instead of
>> individually).
>can all these counter generate interrupt on overflow ?

I believe so, yes.

>How can you specify reset count inividually ?

Again, I beleive so.

>An url for documentation ?

Unfortunately, double secret proprietary - although Apple's documentation of
the G5 performance tools might be a start.  The intent would be to push the
resulting code through our internal open-source clearance process, and then
hopefully into the PPC64 Linux kernel patches.  Unfortunately, I'm not yet
aware of what exactly will be permitted to be open-sourced (ie. not all
performance counters may be publically available).

>>  I was wondering if there was any sort of existing
>> methodology about how to configure events as groups instead of as
>> individual counters.
>Not for the moment, I think this must be solved in userspace, we planned
>to add some sort of event name aliasing, the goal is to provide consistent
>event name across different arch for some commonly used event (branch/L1
>miss etc). This can be probably extended to map an event name to more than
>one counter but how counter can get there reset count on overflow ?
>event aliases is a 0.9 things in our TODO file

Perhaps I misrepresented things in my first message, you can individually
configure events, but only certain events can be used at the same time.
This results in event groups which are made up of various "valid"
combinations of events and particular counters.  The stuff seems very
complicated, so I'd like to keep determining valid combinations out of
the kernel and solve it in userspace.

I would prefer to solve stuff in user space by having a tool which helps
users select the correct group (or groups) and then have the ability to
program the performance config registers at the toplevel of the filesystem.

Thanks for your help and comments.