Re: PMC strawman

[Allen Briggs <briggs%wasabisystems.com@localhost>]

On Fri, Feb 14, 2003 at 10:51:52AM -0800, Matt Thomas wrote:
> 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).

Sounds good.

> 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.

I'd say add them on the context switch.

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

Sounds right.

> 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?

You mean a glob to treat the PMC registers as part of the context?
If it's only conditionally restored, that seems reasonable to me.
It's what?  Another 44 bytes of mcontext overhead?  It might be
nice to perhaps have a way to avoid that for production system
code, though.  Maybe a compile-time knob?

> 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).

This is something that I kind of ignored with the XScale
implementation.  It would certainly be useful to have,
though I would certainly want to avoid the overhead unless
PERFCTRS is enabled.

> 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.

What do you think this should look like?

-allen

-- 
 Allen Briggs                     briggs%wasabisystems.com@localhost
 Wasabi Systems, Inc.             http://www.wasabisystems.com/