profile Provider

Skip to end of metadata
Go to start of metadata

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

/pid != 0/
        @proc[pid, execname] = count();

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

/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 $$
$ while true ; do let i=0 ; done

In another window, run the D script for a brief period of time:

# dtrace -s ./profpri.d 494621
 dtrace: script './profpri.d' matched 1 probe
           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:

           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.


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.



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:

        @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:

         * 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);

/i++ >= 10/

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

# dtrace -s ./restest.d
 dtrace: script './restest.d' matched 2 probes
CPU     ID                    FUNCTION:NAME
  0  33631                       :tick-1sec 
           value  ------------- Distribution ------------- count    
             < 0 |                                         0        
               0 |@@@                                      10760    
               1 |@@@@                                     10842    
               2 |@@@@                                     10861    
               3 |@@@                                      10820    
               4 |@@@                                      10819    
               5 |@@@                                      10817    
               6 |@@@@                                     10826    
               7 |@@@@                                     10847    
               8 |@@@@                                     10830    
               9 |@@@@                                     10830

On an architecture that does not support arbitrary resolution profile probes, running the example script will yield an uneven distribution:

# dtrace -s ./restest.d
 dtrace: script './restest.d' matched 2 probes
 CPU     ID                    FUNCTION:NAME
  0  28321                       :tick-1sec 
           value  ------------- Distribution ------------- count    
               4 |                                         0        
               5 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  107864   
               6 |                                         424      
               7 |                                         255      
               8 |                                         496      
               9 |                                         0

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.



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 39, Stability.

Element Name stability Data stability Dependency class
Provider Evolving Evolving Common
Module Unstable Unstable Unknown
Function Private Private Unknown
Name Evolving Evolving Common
Arguments Evolving Evolving Common
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 24, 2009

    You have to be careful with the tick provider when not running as root as it will not always fire:

    /usr/sbin/dtrace -n 'tick-1s { printf("%Y", walltimestamp); }'
    dtrace: description 'tick-1s ' matched 1 probe
    CPU     ID                    FUNCTION:NAME
      4  17776                         :tick-1s 2009 Jul 24 16:41:19
      4  17776                         :tick-1s 2009 Jul 24 16:42:45
      4  17776                         :tick-1s 2009 Jul 24 16:44:41
      4  17776                         :tick-1s 2009 Jul 24 16:44:50

    Running as root does not have this issue.

Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.