Lines Matching refs:in
17 built-in Python interpreter. It reads and processes the input file and
18 displays the results of the trace analysis implemented in the given
74 every time a system call occurs in the system. Our script will do
104 That single stream will be recorded in a file in the current directory
109 callback handler for each event type found in the perf.data trace
116 The output file created also in the current directory is named
117 perf-script.py. Here's the file in its entirety:
124 # in the format files. Those fields not available as handler params can
138 print "in trace_begin"
141 print "in trace_end"
171 every event in the 'perf record' output. The handler functions take
173 each field in the event; in this case, there's only one event,
179 every time the script finds an event in the perf.data file that
180 doesn't correspond to any event handler in the script. This could
182 really interested in, or the script was run against a trace file that
186 event found in the trace stream i.e. it basically just dumps the event
208 Of course, for this script, we're not interested in printing every
209 trace event, but rather aggregating it in a useful way. So we'll get
225 print "in trace_end"
250 (implemented in Core.py) that implements Perl's 'autovivifying' hashes
251 in Python i.e. with autovivifying hashes, you can assign nested hash
256 object itself, the initial value is assigned in the TypeError
257 exception. Well, there may be a better way to do this in Python but
264 The print_syscall_totals() function iterates over the entries in the
269 displayed after all the events in the trace have been processed, by
273 The final script producing the output shown above is shown in its
311 for id, val in sorted(syscalls.iteritems(), key = lambda(k, v): (v, k), \
320 So those are the essential steps in writing and running a script. The
322 you're interested in - basically find the tracepoint(s) you're
323 interested in by looking at the list of available events shown by
324 'perf list' and/or look in /sys/kernel/debug/tracing events for
332 writing a couple of very simple shell scripts and putting them in the
348 To have the script appear as a 'built-in' script, you write two simple
353 into the perf/scripts/python/bin directory in the kernel source tree.
365 your script, but with -report appended. It should also be located in
377 Note that the location of the Python script given in the shell script
378 is in the libexec/perf-core/scripts/python directory - this is where
381 to be located in the perf/scripts/python directory in the kernel
423 python' in the same directory as an existing perf.data trace file.
425 the event types in the trace file; it simply prints every available
426 field for each event in the trace file.
428 You can also look at the existing scripts in
438 'handler function' is called for each event in the trace. If there's
448 all sched_wakeup events in the system:
483 The common_* arguments in the handler's argument list are the set of
485 to the common_* fields in the format file, but some are synthesized,
492 context an opaque 'cookie' used in calls back into perf
499 All of the remaining fields in the event's format file have
501 seen in the example above.
504 every event in a trace, which covers 90% of what you need to know to
526 functions in any order.
559 built-in perf script Python modules and their associated functions.
583 dictionary that implements Perl's 'autovivifying' hashes in Python
594 Some of the 'common' fields in the event format file aren't all that
598 access this data in the context of the current event. Each of these
615 nsecs_str(nsecs) - returns printable string in the form secs.nsecs