profile Provider

The profile provider provides probes associated with a time-based interrupt firing every fixed,
specified time interval. These unanchored probes that are not associated with any
particular point of execution, but rather with the asynchronous interrupt event. These probes can
be used to sample some aspect of system state every unit time
and the samples can then be used to infer system behavior. If the
sampling rate is high, or the sampling time is long, an accurate inference
is possible. Using DTrace actions, the profile provider can be used to sample practically
anything in the system. For example, you could sample the state of the
current thread, the state of the CPU, or the current machine instruction.

profile-n probes

A profile-n probe fires every fixed interval on every CPU at high
interrupt level. The probe's firing interval is denoted by the value of n:
the interrupt source will fire n times per second. n may also have an
optional time suffix, in which case n is interpreted to be in the
units denoted by the suffix. Valid suffixes and the units they denote are
listed in Table 11-5.

Table 11-5 Valid time suffixes

Suffix

Time Units

nsec or ns

nanoseconds

usec or us

microseconds

msec or ms

milliseconds

sec or s

seconds

min
or m

minutes

hour or h

hours

day or d

days

hz

hertz (frequency per second)

The following example creates a probe to fire at 97 hertz to
sample the currently running process:

You can also use the profile-n provider to sample information about the
running process. The following example D script uses a 1,001 hertz profile probe
to sample the current priority of a specified process:

This output shows the bias of the timesharing scheduling class. Because the shell
process is spinning on the CPU, its priority is constantly being lowered by
the system. If the shell process were running less frequently, its priority would
be higher. To see this result, type Control-C in the spinning shell and
run the script again:

Because the shell process was sleeping awaiting user input instead of spinning on
the CPU, when it did run it was run at a much higher
priority.

tick- n probes

Like profile-n probes, tick-n probes fire every fixed interval at
high interrupt level. However, unlike profile-n probes, which fire on every CPU, tick-n probes fire on only one CPU per interval. The actual CPU may
change over time. As with profile-n probes, n defaults to rate-per-second
but may also have an optional time suffix. tick-n probes have several uses,
such as providing some periodic output or taking a periodic action.

Arguments

The arguments to profile probes are as follows:

arg0

The program counter (PC) in
the kernel at the time that the probe fired, or 0 if the
current process was not executing in the kernel at the time that the
probe fired

arg1

The PC in the user-level process at the time that the
probe fired, or 0 if the current process was executing at the kernel
at the time that the probe fired

As the descriptions imply, if arg0 is non-zero then arg1 is zero;
if arg0 is zero then arg1 is non-zero. Thus, you can use arg0
and arg1 to differentiate user-level from kernel level, as in this simple example:

profile-1ms
{
@ticks[arg0 ? "kernel" : "user"] = count();
}

Timer Resolution

The profile provider uses arbitrary resolution interval timers in the operating system. On
architectures that do not support truly arbitrary resolution time-based interrupts, the frequency is
limited by the system clock frequency, which is specified by the hz kernel variable.
Probes of higher frequency than hz on such architectures will fire some number
of times every 1/hz seconds. For example, a 1000 hertz profile probe on
such an architecture with hz set to 100 will fire ten times in
rapid succession every ten milliseconds. On platforms that support arbitrary resolution, a 1000 hertz
profile probe would fire exactly every one millisecond.

The following example tests a given architecture's resolution:

profile-5000
{
/*
* We divide by 1,000,000 to convert nanoseconds to milliseconds, and
* then we take the value mod 10 to get the current millisecond within
* a 10 millisecond window. On platforms that do not support truly
* arbitrary resolution profile probes, all of the profile-5000 probes
* will fire on roughly the same millisecond. On platforms that
* support a truly arbitrary resolution, the probe firings will be
* evenly distributed across the milliseconds.
*/
@ms = lquantize((timestamp / 1000000) % 10, 0, 10, 1);
}
tick-1sec
/i++ >= 10/
{
exit(0);
}

On an architecture that supports arbitrary resolution profile probes, running the example script
will yield an even distribution:

On these architectures, hz may be manually tuned in /etc/system to improve the
effective profile resolution.

Currently, all variants of UltraSPARC (sun4u) support arbitrary resolution profile probes. Many variants
of the x86 architecture (i86pc) also support arbitrary resolution profile probes, although some
older variants do not.

Probe Creation

Unlike other providers, the profile provider creates probes dynamically on an as-needed basis.
Thus, the desired profile probe might not appear in a listing of all
probes (for example, by using dtrace -l -P profile) but the probe will be created
when it is explicitly enabled.

On architectures that support arbitrary resolution profile probes, a time interval that is
too short would cause the machine to continuously field time-based interrupts, thereby denying
service on the machine. To prevent this situation, the profile provider will silently
refuse to create any probe that would result in an interval of less
than two hundred microseconds.

Stability

The profile provider uses DTrace's stability mechanism to describe its stabilities as shown
in the following table. For more information about the stability mechanism, see Chapter 18, Stability.