Lines Matching full:event
2 Event Tracing
13 using the event tracing infrastructure.
15 Not all tracepoints can be traced using the event tracing system;
20 2. Using Event Tracing
29 To enable a particular event, such as 'sched_wakeup', simply echo it
36 To disable an event, echo the event name to the set_event file prefixed
50 etc., and a full event name looks like this: <subsystem>:<event>. The
64 To enable event 'sched_wakeup'::
85 - ? - this file does not affect any event
92 trace_event=[event-list]
94 event-list is a comma separated list of events. See section 2.1 for event
97 3. Defining an event-enabled tracepoint
102 4. Event formats
105 Each trace event has a 'format' file associated with it that contains
106 a description of each field in a logged event. This information can
108 find the field names that can be used in event filters (see section 5).
111 event in text mode, along with the event name and ID used for
114 Every event has a set of ``common`` fields associated with it; these are
117 definition for that event.
127 event::
149 This event contains 10 fields, the first 5 common and the remaining 5
150 event-specific. All the fields for this event are numeric, except for
151 'comm' which is a string, a distinction important for event filtering.
153 5. Event filtering
157 'filter expressions' with them. As soon as an event is logged into
159 associated with that event type. An event with field values that
160 'match' the filter will appear in the trace output, and an event whose
161 values don't match will be discarded. An event with no filter
163 filter has been set for an event.
171 logged event with a constant value and returns either 0 or 1 depending
213 A filter for an individual event is set by writing a filter expression
214 to the 'filter' file for the given event.
255 To clear the filter for an event, write a '0' to the event's filter
264 For convenience, filters for every event in a subsystem can be set or
267 event within the subsystem lacks a field specified in the subsystem
269 filter for that event will retain its previous setting. This can
328 6. Event triggers
334 a stack trace whenever the trace event is hit. Whenever a trace event
336 associated with that event is invoked. Any given trigger can
337 additionally have an event filter of the same form as described in
338 section 5 (Event filtering) associated with it - the command will only
339 be invoked if the event being invoked passes the associated filter.
342 Triggers are added to and removed from a particular event by writing
343 trigger expressions to the 'trigger' file for the given event.
345 A given event can have any number of triggers associated with it,
349 Event triggers are implemented on top of "soft" mode, which means that
350 whenever a trace event has one or more triggers associated with it,
351 the event is activated even if it isn't actually enabled, but is
355 enabled, and also allows the current event filter implementation to be
358 The syntax for event triggers is roughly based on the syntax for
385 The filter syntax is the same as that described in the 'Event
400 These commands can enable or disable another trace event whenever
401 the triggering event is hit. When these commands are registered,
402 the other trace event is activated, but disabled in a "soft" mode.
404 The event tracepoint stays in this mode as long as there's a trigger
423 enable_event:<system>:<event>[:count]
424 disable_event:<system>:<event>[:count]
435 per triggering event, but there can only be one trigger per
436 triggered event. e.g. sys_enter_read can have triggers enabling both
445 triggering event occurs.
478 event.
483 triggering event occurs.
488 capture those events when the trigger event occurred::
507 event.
519 trigger event::
538 triggering event.
542 This command aggregates event hits into a hash table keyed on one or
543 more trace event format fields (or stacktrace) and a set of running
544 totals derived from one or more trace event format fields and/or
545 event counts (hitcount).
549 7. In-kernel trace event API
561 The trace event subsystem provides an in-kernel API allowing modules
569 Both the synthetic event and k/ret/probe event APIs are built on top
570 of a lower-level "dynevent_cmd" event command API, which is also
572 higher-level trace event APIs.
577 - dynamically creating synthetic event definitions
578 - dynamically creating kprobe and kretprobe event definitions
582 7.1 Dyamically creating synthetic event definitions
585 There are a couple ways to create a new synthetic event from a kernel
588 The first creates the event in one step, using synth_event_create().
589 In this method, the name of the event to create and an array defining
591 synthetic event with that name and fields will exist following that
592 call. For example, to create a new "schedtest" synthetic event::
598 synth_field_desc, each of which describes an event field by type and
616 be a dynamic array, which will only take as much space in the event as
619 Because space for an event is reserved before assigning field values
620 to the event, using dynamic arrays implies that the piecewise
625 If the event is created from within a module, a pointer to the module
630 At this point, the event object is ready to be used for generating new
633 In the second method, the event is created in several steps. This
637 To use this method, an empty or partially empty synthetic event should
640 the name of the event along with one or more pairs of args each pair
643 event along with an array of struct synth_field_desc should be
648 For example, to create a new "schedtest" synthetic event with two
670 Once the synthetic event object has been created, it can then be
691 Once all the fields have been added, the event should be finalized and
696 At this point, the event object is ready to be used for tracing new
702 To trace a synthetic event, there are several options. The first
703 option is to trace the event in one call, using synth_event_trace()
711 7.2.1 Tracing a synthetic event all at once
714 To trace a synthetic event all at once, the synth_event_trace() or
718 representing the synthetic event (which can be retrieved using
719 trace_get_event_file() using the synthetic event name, "synthetic" as
722 synthetic event field, and the number of values being passed.
724 So, to trace an event corresponding to the synthetic event definition
738 the event for the string, using these pointers.
742 representing the synthetic event (which can be retrieved using
743 trace_get_event_file() using the synthetic event name, "synthetic" as
746 event field.
748 To trace an event corresponding to the synthetic event definition
762 match the number of field in the synthetic event, and which must be in
763 the same order as the synthetic event fields.
767 the event for the string, using these pointers.
769 In order to trace a synthetic event, a pointer to the trace event file
778 Before tracing the event, it should be enabled in some way, otherwise
779 the synthetic event won't actually show up in the trace buffer.
781 To enable a synthetic event from the kernel, trace_array_set_clr_event()
785 To enable the event, pass 'true' to it::
796 event, which should be visible in the trace buffer afterwards::
801 To remove the synthetic event, the event should be disabled, and the
809 remove the event::
813 7.2.2 Tracing a synthetic event piecewise
818 event trace::
824 It's passed the trace_event_file representing the synthetic event
829 Once the event has been opened, which means space for it has been
832 the event, which requires no lookups, or by name, which does. The
839 along with the value to set the next field in the event. After each
884 incompatible if used within the same trace of an event - either one
887 Finally, the event won't be actually traced until it's 'closed',
897 7.3 Dyamically creating kprobe and kretprobe event definitions
900 To create a kprobe or kretprobe trace event from kernel code, the
904 To create a kprobe event, an empty or partially empty kprobe event
906 of the event and the probe location should be specfied along with one
912 For example, to create a new "schedtest" kprobe event with two fields::
924 * Define the gen_kprobe_test event with the first 2 kprobe
930 Once the kprobe event object has been created, it can then be
938 Once all the fields have been added, the event should be finalized and
949 At this point, the event object is ready to be used for tracing new
952 Similarly, a kretprobe event can be created using
959 Similar to the synthetic event case, code like the following can be
960 used to enable the newly created kprobe event::
968 used to give the kprobe event file back and delete the event::
977 Both the in-kernel synthetic event and kprobe interfaces are built on
983 layer that can be used to generate trace event commands. The
985 and event creation code that already exists in the trace event
1013 correct command type, and a pointer to an event-specific run_command()
1014 callback that will be called to actually execute the event-specific
1069 At that point, if the return value is 0, the dynamic event has been