OProfile issues

[Stephane Eranian <eranian@hpl.hp.com>]

Hello,

I am working on perfmon2 to allow Oprofile and perfmon2 to co-exist
as suggested by Andi Kleen. I looked at the Oprofile init/shutdown
code and I am puzzled by several things which you might be able to
explain for me. I am looking at 2.6.22-rc3.

Here are the issues:

 * model->fill_in_addresses is called once for all CPUs
   on X86, it does more than just filling in the addresses,
   it also coordinates with the NMI watchdog by reserving
   registers via the reserve_*nmi() interface.

   The problem is that the release of the registers is done
   in model->shutdown() which happens to be executed on every
   CPU. So you end up releasing the registers too many times.
   This is *not* harmless once you start sharing the PMU with
   other subsystems given the way the allocator is designed.

 * allocate_msrs() allocates two tables per CPU. One for the
   counters, the other for the eventsel registers. But then
   nmi_setup() copies the cpu_msrs[0] into cpu_msrs[] of all
   other cpus. This operation overrides the cpu_msrs[].counters
   and cpu_msrs[].controls pointers for all CPUs but CPU0.
   But free_msrs() will free the same tables multiple times. This
   causes a kernel dump when you enable certain kernel debugging
   features. The fix is to copy the content of the counters and
   controls array, not the pointers.

 * the fill_in_addresses() callback for X86 invokes the NMI watchdog
   reserve_*_nmi() register allocation routines. This is done regardless
   of whether the NMI watchdog is active. When the NMI watchdog is not
   active, the allocator will satisfy the allocation for the first MSR
   of each type (counter or control), but then it will reject any
   request for the others. You end up working with a single
   counter/control register.

Are those known bugs?

-- 
-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/