| blob | b697639e767bd018a3c3d281ea8bea2d80bd3ec9 |
1 .\" $NetBSD: 2.t,v 1.2 1998/01/09 06:41:19 perry Exp $
2 .\"
3 .\" Copyright (c) 1984 The Regents of the University of California.
4 .\" All rights reserved.
5 .\"
6 .\" Redistribution and use in source and binary forms, with or without
7 .\" modification, are permitted provided that the following conditions
8 .\" are met:
9 .\" 1. Redistributions of source code must retain the above copyright
10 .\" notice, this list of conditions and the following disclaimer.
11 .\" 2. Redistributions in binary form must reproduce the above copyright
12 .\" notice, this list of conditions and the following disclaimer in the
13 .\" documentation and/or other materials provided with the distribution.
14 .\" 3. Neither the name of the University nor the names of its contributors
15 .\" may be used to endorse or promote products derived from this software
16 .\" without specific prior written permission.
17 .\"
18 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
19 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
20 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
21 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
22 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
23 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
24 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
25 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
26 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
27 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28 .\" SUCH DAMAGE.
29 .\"
30 .\" Copyright (c) 1984 M. K. McKusick
31 .\"
32 .\" Redistribution and use in source and binary forms, with or without
33 .\" modification, are permitted provided that the following conditions
34 .\" are met:
35 .\" 1. Redistributions of source code must retain the above copyright
36 .\" notice, this list of conditions and the following disclaimer.
37 .\" 2. Redistributions in binary form must reproduce the above copyright
38 .\" notice, this list of conditions and the following disclaimer in the
39 .\" documentation and/or other materials provided with the distribution.
40 .\" 3. All advertising materials mentioning features or use of this software
41 .\" must display the following acknowledgement:
42 .\" This product includes software developed by the University of
43 .\" California, Berkeley and its contributors.
44 .\" 4. Neither the name of the University nor the names of its contributors
45 .\" may be used to endorse or promote products derived from this software
46 .\" without specific prior written permission.
47 .\"
48 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
49 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
50 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
51 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
52 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
53 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
54 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
55 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
56 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
57 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
58 .\" SUCH DAMAGE.
59 .\"
60 .\" @(#)2.t 1.3 (Berkeley) 11/8/90
61 .\"
62 .ds RH The \fIgprof\fP Profiler
63 .NH 1
64 The \fIgprof\fP Profiler
65 .PP
66 The purpose of the \fIgprof\fP profiling tool is to
67 help the user evaluate alternative implementations
68 of abstractions.
69 The \fIgprof\fP design takes advantage of the fact that the kernel
70 though large, is structured and hierarchical.
71 We provide a profile in which the execution time
72 for a set of routines that implement an
73 abstraction is collected and charged
74 to that abstraction.
75 The profile can be used to compare and assess the costs of
76 various implementations [Graham82] [Graham83].
77 .NH 2
78 Data presentation
79 .PP
80 The data is presented to the user in two different formats.
81 The first presentation simply lists the routines
82 without regard to the amount of time their descendants use.
83 The second presentation incorporates the call graph of the
84 kernel.
85 .NH 3
86 The Flat Profile
87 .PP
88 The flat profile consists of a list of all the routines
89 that are called during execution of the kernel,
90 with the count of the number of times they are called
91 and the number of seconds of execution time for which they
92 are themselves accountable.
93 The routines are listed in decreasing order of execution time.
94 A list of the routines that are never called during execution of
95 the kernel is also available
96 to verify that nothing important is omitted by
97 this profiling run.
98 The flat profile gives a quick overview of the routines that are used,
99 and shows the routines that are themselves responsible
100 for large fractions of the execution time.
101 In practice,
102 this profile usually shows that no single function
103 is overwhelmingly responsible for
104 the total time of the kernel.
105 Notice that for this profile,
106 the individual times sum to the total execution time.
107 .NH 3
108 The Call Graph Profile
109 .PP
110 Ideally, we would like to print the call graph of the kernel,
111 but we are limited by the two-dimensional nature of our output
112 devices.
113 We cannot assume that a call graph is planar,
114 and even if it is, that we can print a planar version of it.
115 Instead, we choose to list each routine,
116 together with information about
117 the routines that are its direct parents and children.
118 This listing presents a window into the call graph.
119 Based on our experience,
120 both parent information and child information
121 is important,
122 and should be available without searching
123 through the output.
124 Figure 1 shows a sample \fIgprof\fP entry.
125 .KF
126 .DS L
127 .TS
128 box center;
129 c c c c c l l
130 c c c c c l l
131 c c c c c l l
132 l n n n c l l.
133 called/total \ \ parents
134 index %time self descendants called+self name index
135 called/total \ \ children
136 _
137 0.20 1.20 4/10 \ \ \s-1CALLER1\s+1 [7]
138 0.30 1.80 6/10 \ \ \s-1CALLER2\s+1 [1]
139 [2] 41.5 0.50 3.00 10+4 \s-1EXAMPLE\s+1 [2]
140 1.50 1.00 20/40 \ \ \s-1SUB1\s+1 <cycle1> [4]
141 0.00 0.50 1/5 \ \ \s-1SUB2\s+1 [9]
142 0.00 0.00 0/5 \ \ \s-1SUB3\s+1 [11]
143 .TE
144 .ce
145 Figure 1. Profile entry for \s-1EXAMPLE\s+1.
146 .DE
147 .KE
148 .PP
149 The major entries of the call graph profile are the entries from the
150 flat profile, augmented by the time propagated to each
151 routine from its descendants.
152 This profile is sorted by the sum of the time for the routine
153 itself plus the time inherited from its descendants.
154 The profile shows which of the higher level routines
155 spend large portions of the total execution time
156 in the routines that they call.
157 For each routine, we show the amount of time passed by each child
158 to the routine, which includes time for the child itself
159 and for the descendants of the child
160 (and thus the descendants of the routine).
161 We also show the percentage these times represent of the total time
162 accounted to the child.
163 Similarly, the parents of each routine are listed,
164 along with time,
165 and percentage of total routine time,
166 propagated to each one.
167 .PP
168 Cycles are handled as single entities.
169 The cycle as a whole is shown as though it were a single routine,
170 except that members of the cycle are listed in place of the children.
171 Although the number of calls of each member
172 from within the cycle are shown,
173 they do not affect time propagation.
174 When a child is a member of a cycle,
175 the time shown is the appropriate fraction of the time
176 for the whole cycle.
177 Self-recursive routines have their calls broken
178 down into calls from the outside and self-recursive calls.
179 Only the outside calls affect the propagation of time.
180 .PP
181 The example shown in Figure 2 is the fragment of a call graph
182 corresponding to the entry in the call graph profile listing
183 shown in Figure 1.
184 .KF
185 .DS L
186 .so fig2.pic
187 .ce
188 Figure 2. Example call graph fragment.
189 .DE
190 .KE
191 .PP
192 The entry is for routine \s-1EXAMPLE\s+1, which has
193 the Caller routines as its parents,
194 and the Sub routines as its children.
195 The reader should keep in mind that all information
196 is given \fIwith respect to \s-1EXAMPLE\s+1\fP.
197 The index in the first column shows that \s-1EXAMPLE\s+1
198 is the second entry in the profile listing.
199 The \s-1EXAMPLE\s+1 routine is called ten times, four times by \s-1CALLER1\s+1,
200 and six times by \s-1CALLER2\s+1.
201 Consequently 40% of \s-1EXAMPLE\s+1's time is propagated to \s-1CALLER1\s+1,
202 and 60% of \s-1EXAMPLE\s+1's time is propagated to \s-1CALLER2\s+1.
203 The self and descendant fields of the parents
204 show the amount of self and descendant time \s-1EXAMPLE\s+1
205 propagates to them (but not the time used by
206 the parents directly).
207 Note that \s-1EXAMPLE\s+1 calls itself recursively four times.
208 The routine \s-1EXAMPLE\s+1 calls routine \s-1SUB1\s+1 twenty times, \s-1SUB2\s+1 once,
209 and never calls \s-1SUB3\s+1.
210 Since \s-1SUB2\s+1 is called a total of five times,
211 20% of its self and descendant time is propagated to \s-1EXAMPLE\s+1's
212 descendant time field.
213 Because \s-1SUB1\s+1 is a member of \fIcycle 1\fR,
214 the self and descendant times
215 and call count fraction
216 are those for the cycle as a whole.
217 Since cycle 1 is called a total of forty times
218 (not counting calls among members of the cycle),
219 it propagates 50% of the cycle's self and descendant
220 time to \s-1EXAMPLE\s+1's descendant time field.
221 Finally each name is followed by an index that shows
222 where on the listing to find the entry for that routine.
223 .NH 2
224 Profiling the Kernel
225 .PP
226 It is simple to build a 4.2BSD kernel that will automatically
227 collect profiling information as it operates simply by specifying the
228 .B \-p
229 option to \fIconfig\fP\|(8) when configuring a kernel.
230 The program counter sampling can be driven by the system clock,
231 or by an alternate real time clock.
232 The latter is highly recommended as use of the system clock results
233 in statistical anomalies in accounting for
234 the time spent in the kernel clock routine.
235 .PP
236 Once a profiling system has been booted statistic gathering is
237 handled by \fIkgmon\fP\|(8).
238 \fIKgmon\fP allows profiling to be started and stopped
239 and the internal state of the profiling buffers to be dumped.
240 \fIKgmon\fP can also be used to reset the state of the internal
241 buffers to allow multiple experiments to be run without
242 rebooting the machine.
243 The profiling data can then be processed with \fIgprof\fP\|(1)
244 to obtain information regarding the system's operation.
245 .PP
246 A profiled system is about 5-10% larger in its text space because of
247 the calls to count the subroutine invocations.
248 When the system executes,
249 the profiling data is stored in a buffer that is 1.2
250 times the size of the text space.
251 All the information is summarized in memory,
252 it is not necessary to have a trace file
253 being continuously dumped to disk.
254 The overhead for running a profiled system varies;
255 under normal load we see anywhere from 5-25%
256 of the system time spent in the profiling code.
257 Thus the system is noticeably slower than an unprofiled system,
258 yet is not so bad that it cannot be used in a production environment.
259 This is important since it allows us to gather data
260 in a real environment rather than trying to
261 devise synthetic work loads.