Re: [perfmon] Re: perfmon2 TODO list (4/4)

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

On Thu, Apr 13, 2006 at 01:02:23PM -0700, Stephane Eranian wrote:

> [...]
> > I think the simplest approach would be to provide the current
> > syscall API set as an in-kernel API set as well.  [...]

> I need to better understand why this has to be done from kernel and
> also under which circumstances. Is this when you insert your probe
> code, i.e., as a result of a user action? Is this when execution
> reaches an instrumentation point (kprobe)? [...]

There are three contexts of interactions being contemplated:

>From a random kprobe handler routine, we'd only ever *read* a counter.

>From a sampling event interrupt, we'd also only *read* a counter.

During session startup/shutdown (plain known user context), we'd only
initialize / tear down the counters.


> [...]  I can more easily see acess from a per-CPU poin of view
> reather than per-thread.

Reading "current thread" values would also be useful, if the
management code was already tracking that state (context-switching
it).

> [...]
> System-wide is across all threads running on a CPU by definition.

(We hope to address reasonable configurations of SMP data gathering also.)


> > > Some options to get context setup:
> > > 	-generate bit patterns when compiling systemtap script
> > > 		and generate static array with information for context,
> > > 		pmc, and pmd setup.

This is what we hope to do.  That means that we only would need the
low-level register manipulation API in the kernel, and not the
abstract event naming, configuration/compatibility checking, etc.

> > This approach might relieve us from having to provide the in-kernel API 
> > discussed above.
>
> I looked at Will's proposal at:
> 	http://sources.redhat.com/ml/systemtap/2006-q1/msg00800.html
> There is something confusing about this proposal. I don't know
> at which level this interface operates:  kernel or user? [...]

My followup to that message will clarify this.


> In general I do not think that passing event names to the kernel is
> a good idea.  [...]  This is something better done in a user
> library. But maybe you meant the string contains the value and the
> PMU register to program instead of the logical event name.

That is correct.  During systemtap script compilation, the event names
would be translated to low level PMU register configurations.

- FChE