>> I don't see how this conflicts with using overflow interrupts,
>> started looking into stuff.
>possibly it'll work on powerpc, problem come from some architecture
>we need to re-write the counter value in the interrupt handler and
>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
>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
> I found power4 reference manual, is it a roughly correct base ?
Yeah, that should cover the architectures I'm interested
>> Perhaps I misrepresented things in my first message, you can individually
>> configure events, but only certain events can be used at the same
>> This results in event groups which are made up of various "valid"
>> combinations of events and particular counters. The stuff
>> complicated, so I'd like to keep determining valid combinations
>> the kernel and solve it in userspace.
>ha ok, we have a sort of mechanism already in place, basically the
>description file is in the form ($oprofile_dir/events/*) :
>EVENT_NAME_A:#event_nr counters: 0, 1, 2, 3 other field describing
>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
going to start with a user-space wrapper which handles
configuration and sets the appropriate configuration
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,