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 19-1.
Table 19-1 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:
#pragma D option quiet
profile-97
/pid != 0/
{
@proc[pid, execname] = count();
}
END
{
printf("%-8s %-40s %s\n", "PID", "CMD", "COUNT");
printa("%-8d %-40s %@d\n", @proc);
}
Running the above example for a brief period of time results in
output similar to the following example:
# dtrace -s ./prof.d
^C
PID CMD COUNT
223887 sh 1
100360 httpd 1
100409 mibiisa 1
223887 uname 1
218848 sh 2
218984 adeptedit 2
100224 nscd 3
3 fsflush 4
2 pageout 6
100372 java 7
115279 xterm 7
100460 Xsun 7
100475 perfbar 9
223888 prstat 15
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:
profile-1001
/pid == $1/
{
@proc[execname] = lquantize(curlwpsinfo->pr_pri, 0, 100, 10);
}
To see this example script in action, type the following commands in one
window:
$ echo $$
12345
$ while true ; do let i=0 ; done
In another window, run the D script for a brief period of
time, replacing 12345 with the PID that your echo command returned:
# dtrace -s ./profpri.d 12345
dtrace: script './profpri.d' matched 1 probe
^C
ksh
value ------------- Distribution ------------- count
< 0 | 0
0 |@@@@@@@@@@@@@@@@@@@@@ 7443
10 |@@@@@@ 2235
20 |@@@@ 1679
30 |@@@ 1119
40 |@ 560
50 |@ 554
60 | 0
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:
# dtrace -s ./profpri.d 494621
dtrace: script './profpri.d' matched 1 probe
Now in the shell, type a few characters. When you terminate the
DTrace script, output like the following example will appear:
ksh
value ------------- Distribution ------------- count
40 | 0
50 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 14
60 | 0
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.