Hi, Here are the patches we've been working on to add Cell support to Perfmon2. This code is enough to do some useful monitoring, but is not fully complete. It supports system-wide and per-process monitoring and multiple event-sets. There are still some rough edges, but I think there's enough at least to post for discussion.
It does not yet support the hardware sampling features available in the Cell PMU. We are still developing a separate sampling module to support this. It also does not yet properly support SMT (multiple hardware threads). For now, the user must not start more than one per-process perfmon context on the system, or different hardware threads may try to use the same PMU on one physical CPU. Carl will be posting an email soon on the SMT issues and some ideas with how we might handle them. We've split this up into several patches so each portion of new functionality can be discussed separately. These includes many changes to the powerpc "core" code, as well as changes to the existing power5 and ppc32 code. 1/7 Initial Perfmon2 support for Cell. Add Cell to the kernel build files. Create perfmon_cell.c with the PMC and PMD register layouts, probe_pmu() routine, and other required data structures. The field definitions of the pmX_event PMC registers in the pfm_cell_pmc_desc structure may change. However, since no user-space tools actually use this code yet, it shouldn't be a problem to change those definitions in the near future. 2/7 Add read_pmd and write_pmc/pmd function pointers to the pfm_arch_pmu_info structure. This will allow the powerpc common code to call the model-specific routines to read/write the desired registers. Then we can remove the model-specific code from the powerpc common code. For Cell, the control registers are split into three "groups" - the per-counter control registers, the per-counter event registers, and the global control registers. This also adds the routines for making the RTAS calls to the firmware, which is used for writing the per-counter event registers. 3/7 Add "enable_counters" and "disable_counters" function pointers to the pfm_arch_pmu_info structure. Implement these routines in all of the powerpc model-specific modules. enable_counters is called from pfm_arch_start(), and disable_counters is called from pfm_stop_active(). The existing code from those two routines was moved to the power5 and ppc32 modules. Calls to enable_counters are also added to pfm_arch_ctxswin_thread() and to pfm_arch_intr_unfreeze_pmu(). 4/7 Create optional model-specific restore_pmds() and restore_pmcs() entries in the function table in the pfm_arch_pmu_info structure. Cell benefits quite a bit from this, since it can combine all the per-counter "event" registers into one call to the firmware. The other powerpc models are probably alright with the "default" method of restoring PMCs and PMDs one at a time. 5/7 Add PMU interrupt-handling support for Cell. Currently this only processes the counter-overflow interrupts. Interval timer and trace buffer interrupts are currently ignored. 6/7 Add a call to pfm_handle_switch_timeout() to the PowerPC timer_interrupt() routine, so we can switch event-sets based on timeouts. 7/7 Make the RTAS call to reset the debug-bus signals any time a context is removed from the PMU. This way other contexts don't need to worry about what state the bus is in when they get loaded onto the PMU. For self-monitored or system-wide contexts, reset the bus during the unload-context call. Externally monitored contexts don't need to call the bus-reset, since they must already have been context-switched off the CPU (or have already exited). For self-monitored or externally-monitored contexts, reset the bus when the monitored thread is context-switched out. System-wide contexts are not attached to a specific process, so they never get switched out. Thanks, -- Kevin Corry [EMAIL PROTECTED] http://www.ibm.com/linux/ _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
