This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Frank,

On Thu, Apr 13, 2006 at 04:22:11PM -0400, Frank Ch. Eigler wrote:
> 
> > 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.
> 
This can happen at any time and anywhere in the kernel, including
in critical sections. Is that correct? Similarly, can this happen
in sections of code where virtual addressing is turned off?

> >From a sampling event interrupt, we'd also only *read* a counter.
> 
Ok. I can see you  possibly reading a bunch of counters. The key is that on
counter overflow you want to get called.

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

I have another question related maybe more to kprobes and how the intercept
is done: breakpoints, code rewriting. If you use breakpoints, then I wonder
how this works in SMP machines. Do you intervene on each CPU? Another
way to ask this: during intialize/tear down of a script, do you need to operate
only in one CPU or you have some state to propagate to the other CPUs as well.

For the PMU, you need to program the counters on all CPUs (system-wide). The current
design requires that a context be created and bound to each CPU. 

Can you clarify how systemTap works in this area?

-- 
-Stephane


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]