perf_counter vs. oprofile

perf_counter vs. oprofile

[David Miller]

Paul, I just noticed that right now if perf counter is enabled, the
oprofile module load will always fail because the powerpc perf counter
support unconditionally grabs the PMC hardware using
reserve_pmc_hardware() in an arch_initcall()

There really needs to be a way to segregate these multiple users of
the PMC device.  For example, if I'm not using the perf counter
APIs at all I should be able to use oprofile if I want to.

Anyways, just FYI...

Re: perf_counter vs. oprofile

[Paul Mackerras]

David Miller writes:

> Paul, I just noticed that right now if perf counter is enabled, the
> oprofile module load will always fail because the powerpc perf counter
> support unconditionally grabs the PMC hardware using
> reserve_pmc_hardware() in an arch_initcall()
> 
> There really needs to be a way to segregate these multiple users of
> the PMC device.  For example, if I'm not using the perf counter
> APIs at all I should be able to use oprofile if I want to.
> 
> Anyways, just FYI...

Sure.  I know the current situation is distinctly sub-optimal but I
wanted to get something going so I could start playing with it.  (All
the perf_counter stuff is very much beta code at the moment IMHO.)
What I intend to do is claim the PMU when the first counter gets
opened and release it when the last counter gets closed, but that will
need some support in the core, I think.  I'm on vacation at the moment
and travelling, so I won't get to it in the next two weeks though. :)

Out of curiosity, what ppc hardware are you using perf_counters on?
A G5?

Regards,
Paul.

Re: perf_counter vs. oprofile

[David Miller]

From: Paul Mackerras <paulus@samba.org>
Date: Thu, 22 Jan 2009 18:06:13 +1100

> Out of curiosity, what ppc hardware are you using perf_counters on?
> A G5?

An UltraSPARC-IIIi :-)

I just wanted to make sure you realized the conflict, and you
obviously do.