Hi, folks. I'm trying to resolve an apparent contradiction between
the internals doc and the code.
When I look at
2.2. IA64 and perfmon
The IA64 architecture provides a different interface from the
other architectures, using the existing perfmon
driver. Register programming is handled entirely in user-space
(see daemon/opd_perfmon.c for the details). A process is
forked for each CPU, which creates a perfmon context and sets
the counter registers appropriately via the sys_perfmonctl
interface. In addition, the actual initiation and termination
of the profiling session is handled via the same interface
using PFM_START and PFM_STOP. On IA64, then, there are no
oprofilefs files for the performance counters, as the kernel
driver does not program the registers itself.
Instead, the perfmon driver for OProfile simply registers with
the OProfile core with an OProfile-specific UUID. During a
profiling session, the perfmon core calls into the OProfile
perfmon driver and samples are registered with the OProfile
core itself as usual (with oprofile_add_sample()).
but when I look at
I see lots of evidence that you take over the PMU:
#define MY_OPROFILE_VECTOR (IA64_PERFMON_VECTOR - 2)
and you program the PMU yourself:
op_raw_pmu_interrupt(int irq, void *arg, struct pt_regs *regs)
These two seem contradictory.
Which is it?
I recall seeing a similar internals doc for 0.5.x and I know from
using it that it programs the PMU itself and creates data files. I'm
wondering if the internals doc is left over from long LONG ago when it
did indeed use perfmon, but that more modern versions bypass perfmon?