Lines Matching refs:variable
89 indicates which type of field it is - key, value, variable, variable
377 map_elt specifically designed to store and retrieve variable values.
378 The diagram below shows those new elements and adds a new variable
379 entry, ts0, corresponding to the ts0 variable in the sched_waking
446 variable. For a normal val hist_field, .flags is just 0 (modulo | | |
447 modifier flags), but if the value is defined as a variable, the .flags | | |
451 into the tracing_map_elts' .vars[] array containing variable values. | | |
452 This idx is used whenever the value of the variable is set or read. | | |
453 The map_elt.vars idx assigned to the given variable is assigned and | | |
465 or val and the .vars[] members point to the value of a variable. The | | |
571 pid 999 is 113345679876, and the timestamp variable in the same | |
579 sched_switch histogram is that it references a variable on the | |
583 but it adds variable references. You can see the normal hitcount and | |
584 key fields along with a new wakeup_lat variable implemented in the | |
585 same way as the sched_waking ts0 variable, but in addition there's an | |
589 members, var.hist_data and var_ref_idx. For a variable reference, the | |
591 a particular variable on a particular histogram. The var_ref_idx is | |
593 each variable whenever a hist trigger is updated. Those resulting | |
696 When a hist trigger makes use of a variable, a new hist_field is
699 variable, as well as the referenced variable's size, type, and
701 variable it references. If a variable reference was created using the
706 because we have a reference to a variable on another histogram, we
707 need to resolve all variable references first. This is done via the
711 variable's var.hist_data along with the current key is used to look up
713 referenced variable's var.idx is used to look up the variable's value
715 the variable for that element, ts0 in the case above. Note that both
716 the hist_fields representing both the variable and the variable
719 Variable and variable reference test
722 This example creates a variable on the sched_waking event, ts0, and
724 creates its own variable, wakeup_lat, but nothing yet uses it::
733 represents a variable. Note that in addition to the variable name,
735 index into the tracing_map_elt.vars[] array of the actual variable
781 to the unused wakeup_lat variable, we see a new section displaying
782 variable references. Variable references are displayed in a separate
788 variable on the sched_waking trigger, $ts0. Looking at the details,
789 we can see that the var.hist_data value of the referenced variable
792 variable. Also displayed is the var_ref_idx value for that variable
793 reference, which is where the value for that variable is cached for
837 variable reference fields:
860 wakeup_lat variable, namely send it and another field as a synthetic
873 variables. In this case, $wakeup_lat is obviously a variable, but
878 the covers, a temporary variable is created for the named field, and
879 this variable is what is actually passed to the trace handler. In the
880 code and documentation, this type of variable is called a 'field
881 variable'.
886 synthetic events) and use that special histogram field as a variable.
904 means it will be automatically converted into a field variable::
1052 As you can see, for a field variable, two hist_fields are created: one
1053 representing the variable, in this case next_pid, and one to actually
1055 field does. These are created separately from normal variable
1059 $next_pid variable in the trace() action.
1061 Note that $wakeup_lat is also a variable reference, referencing the
1070 variable at the var.idx offset in the appropriate tracing_map_elt's
1071 variable at elt->vars[var.idx].
1092 trace() action field variable test
1096 of the wakeup_lat variable, but in addition also creates a couple of
1110 to the wakeup_lat variable, and finally use it along with a couple
1167 the actual variable locations for those variables in the
1171 also that those are the same values displayed for the variable
1172 references corresponding to those variables in the variable reference
1175 the matching - you can see that the first variable refers to the 0
1177 associated with that trigger), while the second variable refers to the
1179 variable references.
1225 variable reference fields:
1320 finally all those variable values are collected via references to them
1374 save() action field variable test
1444 reference to the variable being tracked, in this case the $wakeup_lat
1445 variable. In order to perform the onmax() handler function, there
1446 also needs to be a variable that tracks the current maximum by getting
1448 an auto-generated variable named ' __max' has been created and is
1449 visible in the actions[].track_data.track_var variable.
1499 variable reference fields:
1624 field variable is created for the other event, but since an existing
1626 histogram with a matching variable is created and used, and we'll see
1641 which is a field name that needs to have a field variable created for
1643 it would seem that it wouldn't be possible to create a field variable
1646 with that is that it's not currently possible to define a new variable
1648 variable to the existing sched_waking histogram. It is however
1651 define the new prio field variable on that.
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
1664 synthetic_prio. This is the field variable created for the prio field
1750 the synthetic_prio variable on sched_waking, and looking at the
1753 normal variable, wakeup_lat, and to a normal field variable, next_pid,
1797 variable reference fields:
1883 but in this case we save the pid in the waking_pid variable::
1895 normal fields, we can see the waking_pid variable::
1948 The sched_switch hist_debug output shows that a variable named
1953 Despite that implementation detail, an alias variable is actually more
1954 like a variable reference; in fact it can be thought of as a reference
1956 variable reference being referenced, in this case, the waking_pid
1959 variable reference it's using, so waking_pid's var_ref_idx is also
1965 as the var_ref_idx of the reference, waking_pid, in the variable
1968 Additionally, once it gets that value, since it is also a variable, it
1972 there's a woken_pid var_ref in the variable refs section. That is the
1973 reference to the woken_pid alias variable, and you can see that it
2031 variable reference fields: