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


The usage models that I understand are important would be:

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

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?
	// we would also need to say that this pmu should be per-process
	// so that we handle 
}

Probe kernel.function("sys_execve")
{
	// need the current value for instructions retired. For each of
the
	// allowed pmu events, do you want these as full text?
	// or parameters to a pmu concept (such as
kernel.pmc(instructions_retired))?
	//
	thread->entry_time = kernel.pmc_instructions_retired
}

Probe kernel.function("sys_execve").return
{
	if (thread->entry_time) {
		delta_instr = kernel.pmc_instructions_retired -
thread->entry_time;
		// some output or statistics based
		// on the number of instructions retired for execve
	}
}

Probe end
{
	// Need to indicate we are done using the pmu
}

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

How would you specify that you want the pmu to be virtualized
per-process? For that matter, if you did want to limit things based on a
range of cpu's, were you thinking of something along the lines of
"kernel.cpu(0-3,7,12).pmc_tlbmiss(4000)"?

-- charles


-----Original Message-----
From: Frank Ch. Eigler [mailto:fche@redhat.com] 
Sent: Monday, June 06, 2005 10:51 AM
To: Spirakis, Charles
Cc: systemtap@sources.redhat.com
Subject: Re: Questions regarding systemtap syntax for profiling...

Hi -

On Mon, Jun 06, 2005 at 10:39:48AM -0700, Spirakis, Charles wrote:

> I've been talking with Will regarding enabling profiling for system 
> tap and I was wondering if you had any thoughts regarding the syntax 
> (or syntax constraints) you would like to see for this area.

If you mean the probe point specification syntax, the general pattern
for these is dot-separated components; each component being an
identifier, with an optional parenthesized string or number literal.
I imagine profiling-related probe points being specified something like
these:

     kernel.time_ms(15)
     kernel.cpu(0).pmc_tlbmiss(4000)

The details don't really matter.  What matters is scoping out the
various degrees of freedom, the various options or filters that compose
naturally.

> Also, I saw in a different email thread there was a concept of 
> $timestamp. What does that translate into? What type of resolution 
> will it have?

Some $-variables like this will expand to whatever expressions that make
sense in kernel land, within the restricted context that probes may run
in.  We haven't listed or specified them in any detail yet.
Something generic like $timestamp may just map to (jiffies_64).


- FChE


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