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

>possibly it'll work on powerpc, problem come from some architecture where
>we need to re-write the counter value in the interrupt handler and this
>write is not atomic so your read in the scheduler can read a semi-updated
>value, on those architecture we can't sleep in the interrupt handler so
>using a spinlock is not a solution.

I understand where this can cause problems now - I guess I'll try getting
this working on PPC first and see how it maps (or fails to map) to other
architectures.

> I found power4 reference manual, is it a roughly correct base ?

Yeah, that should cover the architectures I'm interested in.

>> 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.

>ha ok, we have a sort of mechanism already in place, basically the events
>description file is in the form ($oprofile_dir/events/*) :

>EVENT_NAME_A:#event_nr counters: 0, 1, 2, 3 other field describing the event.
>EVENT_NAME_B:#event_nr counters: 0, 3

Yeah, that helps to some degree buy there are dozens of groups with all
sorts of crazy combinations, and I really didn't want to bloat the driver
with the necessary information to cross-check valid combinations.  I'm
going to start with a user-space wrapper which handles validating the
configuration and sets the appropriate configuration registers through
some arch-specific files at the oprofilefs root.  Once this is working
I can look into something more

I'm a little confused about how unit-masks are used still, but I probably
just need to go re-read the documentation.

> Do you plan to use userspace tools too (oreport etc.) ?


That was the plan, not sure if I'll need to augment any to accomodate
the extensions I wanted.  With a wrapper for opcontrol I should be able
to use sampling as-is.  There's just the question of whether I'd need a
new interface for my context-specific perf counters - I figured I'd be
able to track samples the same way, so things should "just work" - might
need an extension for things like interrupt handlers, etc.

        -eric