| Skip Navigation Links | |
| Exit Print View | |
![]() | man pages section 2: System Calls Oracle Solaris 11 Information Library |
- execution time profile
#include <unistd.h>voidprofil(unsigned short *buff,unsigned intbufsiz,unsigned intoffset,unsigned intscale);
Theprofil() function provides CPU-use statistics by profiling the amount of CPU timeexpended by a program. Theprofil() function generates the statistics by creatingan execution histogram for a current process. The histogram is defined fora specific region of program code to be profiled, and the identifiedregion is logically broken up into a set of equal size subdivisions, eachof which corresponds to a count in the histogram. With eachclock tick, the current subdivision is identified and its corresponding histogram countis incremented. These counts establish a relative measure of how much timeis being spent in each code subdivision. The resulting histogram counts fora profiled region can be used to identify those functions that consumea disproportionately high percentage of CPU time.
Thebuff argument is a buffer ofbufsiz bytes in whichthe histogram counts are stored in an array ofunsigned short int. Once oneof the counts reaches 32767 (the size of a short int), profiling stopsand no more data is collected.
Theoffset,scale, andbufsiz arguments specify the region to beprofiled.
Theoffset argument is effectively the start address of the region tobe profiled.
Thescale argument is a contraction factor that indicates how much smallerthe histogram buffer is than the region to be profiled. More precisely,scale is interpreted as an unsigned 16-bit fixed-point fraction with thedecimal point implied on the left. Its value is the reciprocal of thenumber of bytes in a subdivision, per byte of histogram buffer. Sincethere are two bytes per histogram counter, the effective ratio of subdivisionbytes per counter is one half the scale.
The values ofscale are as follows:
the maximum value ofscale,0xffff (approximately 1), maps subdivisions 2 bytes long to each counter.
the minimum value ofscale (for which profiling is performed),0x0002 (1/32,768), maps subdivision 65,536 bytes long to each counter.
the default value ofscale (currently used bycc-qp),0x4000, maps subdivisions 8 bytes long to each counter.
The values are used within the kernel as follows: when theprocess is interrupted for a clock tick, the value ofoffsetis subtracted from the current value of the program counter (pc), andthe remainder is multiplied byscale to derive a result. That resultis used as an index into the histogram array to locate thecell to be incremented. Therefore, the cell count represents the number oftimes that the process was executing code in the subdivision associated withthat cell when the process was interrupted.
The value ofscale can be computed as (RATIO* 0200000L), whereRATIO is the desired ratio ofbufsiz to profiled region size,and has a value between 0 and 1. Qualitatively speaking, the closerRATIO is to 1, the higher the resolution of the profile information.
The value ofbufsiz can be computed as (size_of_region_to_be_profiled*RATIO).
Profiling is turned off by giving ascale value of 0 or1, and is rendered ineffective by giving abufsiz value of 0.Profiling is turned off when one of theexec family of functions(seeexec(2)) is executed, but remains on in both child and parent processes after afork(2). Profiling is turned off if abuffupdate would cause a memory fault.
Thepcsample(2) function should be used when profiling dynamically-linked programs and 64-bitprograms.
exec(2),fork(2),pcsample(2),times(2),monitor(3C),prof(5)
In Solaris releases prior to 2.6, callingprofil() in a multithreaded programwould impact only the calling LWP; the profile state was not inheritedat LWP creation time. To profile a multithreaded program with a globalprofile buffer, each thread needed to issue a call toprofil() at threadsstart-up time, and each thread had to be a bound thread. Thiswas cumbersome and did not easily support dynamically turning profiling on andoff. In Solaris 2.6, theprofil() system call for multithreaded processes has globalimpact — that is, a call toprofil() impacts all LWPs/threads inthe process. This may cause applications that depend on the previous per-LWPsemantic to break, but it is expected to improve multithreaded programs thatwish to turn profiling on and off dynamically at runtime.
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.Legal Notices | ![]() ![]() |