This is the mail archive of the systemtap@sources.redhat.com 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: Questions regarding systemtap syntax for profiling...


Hi -


"Spirakis, Charles" <charles.spirakis@intel.com> writes:

> [...]
> 1) Stopwatch (aka event counting): For example, see how many
> instructions retired you have for a function
> 2) profiling (ala oprofile/papi): For example, see where your system is
> retiring the most instructions.
> In both of these cases, time is just another event (wallclock and
> process virtual time).

Not quite - in the "stopwatch" case, we don't respond to changes in
the time fluent, but rather to the changes in PC.


> So, a simple example to see the number of instructions retired for
> execve:
> 
> Probe begin
> 	// how do we say we want to start a pmu counter for instructions
>          retired?
> [...]
> 
> Probe kernel.function("sys_execve")
> [...]
> 	// need the current value for instructions retired. [...]
> 	thread->entry_time = kernel.pmc_instructions_retired
> 
> Probe kernel.function("sys_execve").return
> [...]
>     delta_instr = kernel.pmc_instructions_retired - thread->entry_time;
> 
> Probe end
> 	// Need to indicate we are done using the pmu

I suspect a better model would be to associate PMU usage with an
individual probe handler.  How about something like this:

global value
probe kernel.pmc_startwatch("instructions_retired").function("foo") {
      value = $pmc_value;
}
probe kernel.pmc_stopwatch("instructions_retired").function("foo").return {
      delta = $pmc_value - value
}

The translator (via an internal "tapset") would map these patterns to
a pair of underlying normal (kernel.function("foo") / .return) probes,
and also adds extra code to reserve / sample / release the named
counter.


> For profiling, you may want to limit the event to a subset of cpu's, but
> it is more common to be interested in the whole system vs. per-process.
> Based on your email below, I'm assuming you mean:
> 
> Probe kernel.pmc_instructions_retired(1000000)
>   // capture information every 1M instructions. No cpu(0) means
>   // system wide...

Yes.


> How would you specify that you want the pmu to be virtualized
> per-process?

systemtap is unlikely to hook into the kernel deeply enough to
*perform* such virtualization.  If such logic is already present in
pmc management APIs, then systemtap scripts could *activate* that
logic using any old invented syntax, even such as adding a
cpu("0-3,7,12") component to the probe point specification.  The
parsing logic for that string would again best reside within the
translator.


- FChE


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