When a PPC_OEA kernel has options PERFCTRS,

When the system initializes FC/FCM0 will be set in MMCR0 to
disabling counting by default.

only processes being monitored will have PSL_PM enabled (so
that performance counters count).

On context switch, if the executing process has enabled the
performance monitoring unit, MMCR[012], SIAR, will be saved
into the PCB.  For the PMC counters, we can either store
them into the PCB or add their values to the value in the
PCB.  The latter means that they can overflow to 64bits and
the right thing will happen.  When a process resumes
execution, PSL_PM will be checked in the saved SSR1 in the
trapframe.  If set, the above registers will be restored
except for the PMC registers which will be zeroed.

User processes will never be able to override FC/FCP/FCS/
FCM1/FCM0/PMXE in MMCR0, they will be controlled by the
kernel.

Note that to use perfctrs with individual pthreads we need
to add a PMC glob to struct mcontext.  Does anyone have a
problem with that?

But what about the kernel?  I assume that doing performance
of user processes and the kernel concurrently will be desired.
If so, then on user traps and execptions, the user PM context
will need to be saved in the trapframe and then the kernel's
loaded from cpu_info (so it's per-cpu).

Though the current PMC framework doesn't allow for it, it
might be useful for multiple processes/threads to be able to
share one PMC context.

-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message