This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [perfmon] Re: perfmon2 TODO list (4/4)
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Stephane Eranian <eranian at hpl dot hp dot com>
- Cc: perfmon at napali dot hpl dot hp dot com, systemtap at sources dot redhat dot com
- Date: Thu, 13 Apr 2006 18:22:51 -0400
- Subject: Re: [perfmon] Re: perfmon2 TODO list (4/4)
- References: <20060412215747.GJ29245@frankl.hpl.hp.com> <20060412220659.GL29245@frankl.hpl.hp.com> <20060412221256.GM29245@frankl.hpl.hp.com> <200604131201.59232.kevcorry@us.ibm.com> <20060413200223.GD30718@frankl.hpl.hp.com> <20060413202211.GF22490@redhat.com> <20060413215544.GH30718@frankl.hpl.hp.com>
Hi -
On Thu, Apr 13, 2006 at 02:55:44PM -0700, Stephane Eranian wrote:
> [...]
> > >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?
Yes.
> Similarly, can this happen in sections of code where virtual
> addressing is turned off?
I am not familiar enough to know, but I expect so. To the extent that
such conditions are detectable at runtime (akin to in_interrupt()), we
can block access from such contexts at runtime, if that were required.
> > >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.
That's right.
> 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?
That's right: as each CPU trips across a breakpoint, they are made to
run our handler, then single-step across the original instruction,
then resume. It's a multi-step process described in kprobes
documentation. From systemtap's point of view, it's a black box.
> 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.
At the moment, one CPU can do all the initialization.
> 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.
We haven't had to perform explicit multi-CPU initialization, but we
certainly could start, using IPI or a more elaborate mechanism. Setup
is an infrequent, unhurried event.
- FChE