Lines Matching refs:histogram
14 Note: All the ftrace histogram command examples assume the working
19 Also, the histogram output displayed for those commands will be
59 What this does is create a histogram on the sched_waking event using
61 explicitly specified, exists for every histogram regardless.
67 So in this histogram, there's a separate bucket for each pid, and each
71 Each histogram is represented by a hist_data struct.
73 To keep track of each key and value field in the histogram, hist_data
76 histogram val and key in the histogram (variables are also included
77 here, but are discussed later). So for the above histogram we have one
80 value or not, which the above histogram does not.
93 fields[] array is the tracing_map instance created for the histogram,
100 object hashed by a given histogram key.
103 associated key and value fields for the histogram described above. As
149 histogram, with pointers from various parts of the fields[] array | |
164 in the histogram, and this is where the continually aggregated sums | |
165 corresponding to each histogram value are kept. | |
256 with each key and value in the histogram, and each of these correspond
257 to the key and value hist_fields created when the histogram was
273 Basic histogram test
282 will show the trigger info of the histogram it corresponds to, along
283 with the address of the hist_data associated with the histogram, which
285 total hist_fields associated with the histogram along with a count of
296 # event histogram
370 In terms of the histogram data structures, variables are implemented
382 sched_waking histogram
457 Below is a representation of the histogram at run-time, which | | |
570 that histogram entry. So in the above, the timestamp associated with | |
574 sched_switch histogram | |
577 The sched_switch histogram paired with the above sched_waking | |
578 histogram is shown below. The most important aspect of the | |
579 sched_switch histogram is that it references a variable on the | |
580 sched_waking histogram above. | |
582 The histogram diagram is very similar to the others so far displayed, | |
591 a particular variable on a particular histogram. The var_ref_idx is | |
598 histogram referred to before::
705 So, in order to handle an event for the sched_switch histogram,
706 because we have a reference to a variable on another histogram, we
710 sched_switch histogram. For each one of those, the referenced
712 the corresponding tracing_map_elt in that histogram. Once found, the
741 # event histogram
798 # event histogram
865 case if we have a pid in the sched_waking histogram that matches the
884 case we have to generate a new histogram and an unfortunately named
886 synthetic events) and use that special histogram field as a variable.
889 context of the sched_switch histogram using the onmatch() handler and
1067 each field_var created for the histogram, and available from
1122 # event histogram
1186 # event histogram
1460 # event histogram
1612 While the above covers the basics of the histogram internals, there
1625 histogram can't be used, as existing histograms are immutable, a new
1626 histogram with a matching variable is created and used, and we'll see
1647 on an existing histogram, so it's not possible to add a new prio field
1648 variable to the existing sched_waking histogram. It is however
1649 possible to create an additional new 'matching' sched_waking histogram
1660 histogram we've seen in the previous examples, and the second is the
1661 special histogram we created to provide the prio field variable.
1663 Looking at the second histogram below, we see a variable with the name
1665 on that sched_waking histogram::
1669 # event histogram
1709 # event histogram
1749 Looking at the sched_switch histogram below, we can see a reference to
1752 the new histogram. Note also that the other references are to a
1758 # event histogram
1899 # event histogram
1981 # event histogram