Documentation/trace/histogram-design.rst

73 To keep track of each key and value field in the histogram, hist_data
85 which is used to grab the field's data from the ftrace event buffer
87 to an event field in the trace buffer - in these cases the function
88 implementation gets its value from somewhere else).  The flags field
89 indicates which type of field it is - key, value, variable, variable
104 you can see, there are two fields in the fields array, one val field
105 for the hitcount and one key field for the pid key.
243 hist_field_fn_t fn() associated with that field, along with the
244 field's size and offset, is used to grab that subkey's data from the
260 to grab the field's value from the current trace record.  Once it has
261 that value, it simply adds that value to that field's
288 It then goes on to display details for each field, including the
289 field's flags and the position of each field in the hist_data's
375 make use of a new .var.idx field member in struct hist_field, which
467 tracing_map members and the field definitions in the corresponding        | | |
588 Associated with the new var ref field are a couple of new hist_field        | |
697 created with flag HIST_FIELD_FL_VAR_REF.  For a VAR_REF field, the
700 is_signed values.  The VAR_REF field's .name is set to the name of the
732 field with the HIST_FIELD_FL_VAR flag, which indicates that that field
734 contained in the var.name field, it includes the var.idx, which is the
860 wakeup_lat variable, namely send it and another field as a synthetic
866 next_pid field on this sched_switch event, we retrieve the
874 next_pid isn't, since it's just naming a field in the sched_switch
876 save() action does, a special shortcut is implemented to allow field
878 the covers, a temporary variable is created for the named field, and
880 code and documentation, this type of variable is called a 'field
886 synthetic events) and use that special histogram field as a variable.
904 means it will be automatically converted into a field variable::
913 created to implement the field variables.  The details are discussed
1052 As you can see, for a field variable, two hist_fields are created: one
1054 get the value of the field from the trace stream, like a normal val
1055 field does.  These are created separately from normal variable
1058 also created, which is needed to reference the field variables such as
1063 have a hist field entry representing that reference created.
1079 The same process occurs for the field variables associated with the
1092 trace() action field variable test
1097 field variables that then are all passed to the wakeup_latency() trace
1113 are automatically converted into field variables for this purpose::
1163 val fields section, but that the new field variables are not there -
1164 although the field variables are variables, they're held separately in
1165 the hist_data's field_vars[] array.  Although the field variables and
1169 wakeup_lat takes the var.idx = 0 slot, while the field variables for
1271   field variables:
1319 variables or are converted into variables (via field variables), and
1348   for each field i in .synth_event
1374 save() action field variable test
1378 action is used to save field values whenever an onmax() handler
1380 example, the values being saved are also field values, but in this
1388 sched_switch field values whenever we hit a new maximum latency.  For
1452 the 4 params to the save() function have resulted in 4 field variables
1614 tend to create even more confusion.  Those are field variables on other
1618 Test of field variables on other histograms
1622 the sched_switch trigger references a hist trigger field on another
1624 field variable is created for the other event, but since an existing
1630 addition of the prio field::
1641 which is a field name that needs to have a field variable created for
1642 it.  There isn't however any prio field on the sched_switch event so
1643 it would seem that it wouldn't be possible to create a field variable
1644 for it.  The matching sched_waking event does have a prio field, so it
1647 on an existing histogram, so it's not possible to add a new prio field
1651 define the new prio field variable on that.
1661 special histogram we created to provide the prio field variable.
1664 synthetic_prio.  This is the field variable created for the prio field
1753 normal variable, wakeup_lat, and to a normal field variable, next_pid,
1754 the details of which are in the field variables section::
1843   field variables:
1951 set, which is why it appears in the val field section.
2088   field variables: