tracing: 'hist' triggers
Subsystems (3)
PATCH v5 1/10 tracing: Update cond flag when enabling or disabling a trigger
In reply to Tom ZanussiWhen a trigger is enabled, the cond flag should be set beforehand, otherwise a trigger that's expecting to process a trace record (e.g. one with post_trigger set) could be invoked without one.
Likewise a trigger's cond flag should be reset after it's disabled, not before.
--- kernel/trace/trace_events_trigger.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
kernel/trace/trace_events_trigger.c +6 -4
@@ -543,11 +543,12 @@ static int register_trigger(char *glob, struct event_trigger_ops *ops,list_add_rcu (&data->list, &file->triggers); ret++; +update_cond_flag (file);if (trace_event_trigger_enable_disable (file,1 ) <0 ) {list_del_rcu (&data->list); +update_cond_flag (file); ret--; } -update_cond_flag (file); out:return ret; }
@@ -575,8 +576,8 @@ static void unregister_trigger(char *glob, struct event_trigger_ops *ops,if (data->cmd_ops->trigger_type == test->cmd_ops->trigger_type) { unregistered = true;list_del_rcu (&data->list); -update_cond_flag (file);trace_event_trigger_enable_disable (file,0 ); +update_cond_flag (file);break ; } }
@@ -1319,11 +1320,12 @@ static int event_enable_register_trigger(char *glob,list_add_rcu (&data->list, &file->triggers); ret++; +update_cond_flag (file);if (trace_event_trigger_enable_disable (file,1 ) <0 ) {list_del_rcu (&data->list); +update_cond_flag (file); ret--; } -update_cond_flag (file); out:return ret; }
@@ -1344,8 +1346,8 @@ static void event_enable_unregister_trigger(char *glob, (enable_data->file == test_enable_data->file)) { unregistered = true;list_del_rcu (&data->list); -update_cond_flag (file);trace_event_trigger_enable_disable (file,0 ); +update_cond_flag (file);break ; } }
Signature · 1 line
1.9.3
PATCH v5 7/10 tracing: Add 'hist' event trigger command
In reply to Tom Zanussi'hist' triggers allow users to continually aggregate trace events, which can then be viewed afterwards by simply reading a 'hist' file containing the aggregation in a human-readable format.
The basic idea is very simple and boils down to a mechanism whereby trace events, rather than being exhaustively dumped in raw form and viewed directly, are automatically 'compressed' into meaningful tables completely defined by the user.
This is done strictly via single-line command-line commands and without the aid of any kind of programming language or interpreter.
A surprising number of typical use cases can be accomplished by users via this simple mechanism. In fact, a large number of the tasks that users typically do using the more complicated script-based tracing tools, at least during the initial stages of an investigation, can be accomplished by simply specifying a set of keys and values to be used in the creation of a hash table.
The Linux kernel trace event subsystem happens to provide an extensive list of keys and values ready-made for such a purpose in the form of the event format files associated with each trace event. By simply consulting the format file for field names of interest and by plugging them into the hist trigger command, users can create an endless number of useful aggregations to help with investigating various properties of the system. See Documentation/trace/events.txt for examples.
hist triggers are implemented on top of the existing event trigger infrastructure, and as such are consistent with the existing triggers from a user's perspective as well.
The basic syntax follows the existing trigger syntax. Users start an aggregation by writing a 'hist' trigger to the event of interest's trigger file:
# echo hist:keys=xxx:values=yyy [ if filter] > event/trigger
Once a hist trigger has been set up, by default it continually aggregates every matching event into a hash table using the event key and value fields specified.
To view the aggregation at any point in time, simply read the 'hist' file in the same directory as the 'trigger' file:
# cat event/hist
The detailed syntax provides additional options for user control, and is described exhaustively in Documentation/trace/events.txt and in the virtual tracing/README file in the tracing subsystem.
--- include/linux/ftrace_event.h | 1 + kernel/trace/Kconfig | 14 + kernel/trace/Makefile | 1 + kernel/trace/trace.c | 44 ++ kernel/trace/trace.h | 21 + kernel/trace/trace_events.c | 4 + kernel/trace/trace_events_hist.c | 1123 +++++++++++++++++++++++++++++++++++ kernel/trace/trace_events_trigger.c | 29 +- 8 files changed, 1222 insertions(+), 15 deletions(-) create mode 100644 kernel/trace/trace_events_hist.c
include/linux/ftrace_event.h +1 -0
@@ -410,6 +410,7 @@ enum event_trigger_type {ETT_SNAPSHOT = (1 <<1 ),ETT_STACKTRACE = (1 <<2 ),ETT_EVENT_ENABLE = (1 <<3 ), + ETT_EVENT_HIST = (1 << 4), };extern int filter_match_preds (struct event_filter *filter,void *rec);
kernel/trace/Kconfig +14 -0
@@ -528,6 +528,20 @@ config MMIOTRACE See Documentation/trace/mmiotrace.txt. If you are not helping to develop drivers, say N. +config HIST_TRIGGERS + bool "Histogram triggers" + depends on ARCH_HAVE_NMI_SAFE_CMPXCHG + help + Hist triggers allow one or more arbitrary trace event fields + to be aggregated into hash tables and dumped to stdout by + reading a debugfs/tracefs file. They're useful for + gathering quick and dirty (though precise) summaries of + event activity as an initial guide for further investigation + using more advanced tools. + + See Documentation/trace/events.txt. + If in doubt, say N. + config MMIOTRACE_TEST tristate "Test module for mmiotrace" depends on MMIOTRACE && m
kernel/trace/Makefile +1 -0
@@ -54,6 +54,7 @@ obj-$(CONFIG_EVENT_TRACING) += trace_event_perf.o endif obj-$(CONFIG_EVENT_TRACING) += trace_events_filter.o obj-$(CONFIG_EVENT_TRACING) += trace_events_trigger.o +obj-$(CONFIG_HIST_TRIGGERS) += trace_events_hist.o obj-$(CONFIG_BPF_EVENTS) += bpf_trace.o obj-$(CONFIG_KPROBE_EVENT) += trace_kprobe.o obj-$(CONFIG_TRACEPOINTS) += power-traces.o
kernel/trace/trace.c +44 -0
56 lines not on this page · raw message
kernel/trace/trace.h +21 -0
@@ -1098,6 +1098,13 @@ extern struct mutex event_mutex;extern struct list_head ftrace_events;extern const struct file_operations event_trigger_fops; +extern const struct file_operations event_hist_fops; + +#ifdef CONFIG_HIST_TRIGGERS +extern int register_trigger_hist_cmd (void ); +#else +static inline int register_trigger_hist_cmd (void ) {return 0 ; } +#endif extern int register_trigger_cmds (void );extern void clear_event_triggers (struct trace_array *tr);
@@ -1114,6 +1121,20 @@ struct event_trigger_data {struct list_head list; }; +extern void trigger_data_free (struct event_trigger_data *data); +extern int event_trigger_init (struct event_trigger_ops *ops, +struct event_trigger_data *data); +extern int trace_event_trigger_enable_disable (struct ftrace_event_file *file, +int trigger_enable); +extern void update_cond_flag (struct ftrace_event_file *file); +extern void unregister_trigger (char *glob,struct event_trigger_ops *ops, +struct event_trigger_data *test, +struct ftrace_event_file *file); +extern int set_trigger_filter (char *filter_str, +struct event_trigger_data *trigger_data, +struct ftrace_event_file *file); +extern int register_event_command (struct event_command *cmd); +/** * struct event_trigger_ops - callbacks for trace event triggers *
kernel/trace/trace_events.c +4 -0
@@ -1628,6 +1628,10 @@ event_create_dir(struct dentry *parent, struct ftrace_event_file *file)trace_create_file ("trigger" ,0644 , file->dir, file, &event_trigger_fops); +#ifdef CONFIG_HIST_TRIGGERS +trace_create_file ("hist" ,0444 , file->dir, file, + &event_hist_fops); +#endif trace_create_file ("format" ,0444 , file->dir, call, &ftrace_event_format_fops);
kernel/trace/trace_events_hist.c new file +1123 -0
1,123 lines not on this page · raw message
kernel/trace/trace_events_trigger.c +14 -15
@@ -28,8 +28,7 @@static LIST_HEAD (trigger_commands);static DEFINE_MUTEX (trigger_cmd_mutex); -static void -trigger_data_free (struct event_trigger_data *data) +void trigger_data_free (struct event_trigger_data *data) {if (data->cmd_ops->set_filter) data->cmd_ops->set_filter (NULL , data,NULL );
@@ -316,7 +315,7 @@ const struct file_operations event_trigger_fops = {* Currently we only register event commands from __init, so mark this * __init too. */ -static __init int register_event_command (struct event_command *cmd) +__init int register_event_command (struct event_command *cmd) {struct event_command *p;int ret =0 ;
@@ -405,9 +404,8 @@ event_trigger_print(const char *name, struct seq_file *m,* * Return: 0 on success, errno otherwise */ -static int -event_trigger_init (struct event_trigger_ops *ops, -struct event_trigger_data *data) +int event_trigger_init (struct event_trigger_ops *ops, +struct event_trigger_data *data) { data->ref++;return 0 ;
@@ -435,8 +433,8 @@ event_trigger_free(struct event_trigger_ops *ops,trigger_data_free (data); } -static int trace_event_trigger_enable_disable (struct ftrace_event_file *file, -int trigger_enable) +int trace_event_trigger_enable_disable (struct ftrace_event_file *file, +int trigger_enable) {int ret =0 ;
@@ -493,7 +491,7 @@ clear_event_triggers(struct trace_array *tr)* its TRIGGER_COND bit set, otherwise the TRIGGER_COND bit should be * cleared. */ -static void update_cond_flag (struct ftrace_event_file *file) +void update_cond_flag (struct ftrace_event_file *file) {struct event_trigger_data *data;bool set_cond = false;
@@ -570,9 +568,9 @@ out:* Usually used directly as the @unreg method in event command * implementations. */ -static void unregister_trigger (char *glob,struct event_trigger_ops *ops, -struct event_trigger_data *test, -struct ftrace_event_file *file) +void unregister_trigger (char *glob,struct event_trigger_ops *ops, +struct event_trigger_data *test, +struct ftrace_event_file *file) {struct event_trigger_data *data;bool unregistered = false;
@@ -706,9 +704,9 @@ event_trigger_callback(struct event_command *cmd_ops,* * Return: 0 on success, errno otherwise */ -static int set_trigger_filter (char *filter_str, -struct event_trigger_data *trigger_data, -struct ftrace_event_file *file) +int set_trigger_filter (char *filter_str, +struct event_trigger_data *trigger_data, +struct ftrace_event_file *file) {struct event_trigger_data *data = trigger_data;struct event_filter *filter =NULL , *tmp;
@@ -1439,6 +1437,7 @@ __init int register_trigger_cmds(void)register_trigger_snapshot_cmd ();register_trigger_stacktrace_cmd ();register_trigger_enable_disable_cmds (); +register_trigger_hist_cmd ();return 0 ; }
Signature · 1 line
1.9.3
PATCH v5 4/10 tracing: Add get_syscall_name()
In reply to Tom ZanussiAdd a utility function to grab the syscall name from the syscall metadata, given a syscall id.
--- kernel/trace/trace.h | 5 +++++ kernel/trace/trace_syscalls.c | 11 +++++++++++ 2 files changed, 16 insertions(+)
kernel/trace/trace.h +5 -0
@@ -1317,8 +1317,13 @@ int perf_ftrace_event_register(struct ftrace_event_call *call,#ifdef CONFIG_FTRACE_SYSCALLS void init_ftrace_syscalls (void ); +const char *get_syscall_name (int syscall);#else static inline void init_ftrace_syscalls (void ) { } +static inline const char *get_syscall_name (int syscall) +{ +return NULL ; +}#endif #ifdef CONFIG_EVENT_TRACING
kernel/trace/trace_syscalls.c +11 -0
@@ -106,6 +106,17 @@ static struct syscall_metadata *syscall_nr_to_meta(int nr)return syscalls_metadata[nr]; } +const char *get_syscall_name (int syscall) +{ +struct syscall_metadata *entry; + + entry =syscall_nr_to_meta (syscall); +if (!entry) +return NULL ; + +return entry->name; +} +static enum print_line_t print_syscall_enter (struct trace_iterator *iter,int flags,struct trace_event *event)
Signature · 1 line
1.9.3
PATCH v5 5/10 tracing: Add a per-event-trigger 'paused' field
In reply to Tom ZanussiAdd a simple per-trigger 'paused' flag, allowing individual triggers to pause. We could leave it to individual triggers that need this functionality to do it themselves, but we also want to allow other events to control pausing, so add it to the trigger data.
--- kernel/trace/trace.h | 1 + kernel/trace/trace_events_trigger.c | 4 ++++ 2 files changed, 5 insertions(+)
kernel/trace/trace.h +1 -0
@@ -1110,6 +1110,7 @@ struct event_trigger_data {struct event_filter __rcu *filter;char *filter_str;void *private_data; +bool paused;struct list_head list; };
kernel/trace/trace_events_trigger.c +4 -0
@@ -73,6 +73,8 @@ event_triggers_call(struct ftrace_event_file *file, void *rec)return tt;list_for_each_entry_rcu (data, &file->triggers, list) { +if (data->paused) +continue ;if (!rec) { data->ops->func (data, rec);continue ;
@@ -110,6 +112,8 @@ event_triggers_post_call(struct ftrace_event_file *file,struct event_trigger_data *data;list_for_each_entry_rcu (data, &file->triggers, list) { +if (data->paused) +continue ;if (data->cmd_ops->trigger_type & tt) data->ops->func (data, rec); }
Signature · 1 line
1.9.3
RFC PATCH v5 10/10 ftrace: Add function_hist tracer
In reply to Tom ZanussiAdd a new tracer named function_hist:
# cat /sys/kernel/debug/tracing/available_tracers
blk mmiotrace function_hist function_graph wakeup_dl wakeup_rt wakeup irqsoff function nop
# echo function_hist > /sys/kernel/debug/tracing/current_tracer # cat /sys/kernel/debug/tracing/function_hist
This is essentially the same as the kernel function tracer, but instead of logging every function call into the trace buffer, it continually updates a tracing map which keeps a running count for each function.
As such, it provides an exhaustive enumeration of every traceable function called in the kernel since the tracer was enabled, along with the number of times it was called.
Example output from an overnight run:
# cat /sys/kernel/debug/tracing/function_hist
ip: [ffffffff812002d0] inotify_release hitcount: 1
ip: [ffffffff81078c40] param_attr_show hitcount: 1
ip: [ffffffff816e2f20] inet6_csk_bind_conflict hitcount: 1
ip: [ffffffffa04bdf50] intel_modeset_preclose hitcount: 1
ip: [ffffffff812001f0] inotify_free_group_priv hitcount: 1
ip: [ffffffffa04641d0] i915_gem_context_create_ioctl hitcount: 1
ip: [ffffffffa026b100] drm_modeset_lock_all_crtcs hitcount: 1
ip: [ffffffff811fe410] fsnotify_destroy_group hitcount: 1
ip: [ffffffff810785e0] module_attr_show hitcount: 1
.
.
.
ip: [ffffffff8109a3e0] add_wait_queue hitcount: 235927661
ip: [ffffffff81716930] _raw_spin_lock hitcount: 345398436
ip: [ffffffff81713150] _cond_resched hitcount: 378571372
ip: [ffffffff816abe90] unix_poll hitcount: 413026161
ip: [ffffffff815f4510] sock_poll hitcount: 438658385
ip: [ffffffff811dc040] __fdget hitcount: 640844197
ip: [ffffffff811dba90] __fget hitcount: 657582124
ip: [ffffffff811dbfd0] __fget_light hitcount: 662386005
ip: [ffffffff817164f0] _raw_spin_unlock_irqrestore hitcount: 848890816
ip: [ffffffff817168e0] _raw_spin_lock_irqsave hitcount: 849815447
ip: [ffffffff811c09c0] fput hitcount: 892233261
Totals:
Hits: 17981015194
Entries: 5527
Dropped: 0--- kernel/trace/Makefile | 1 + kernel/trace/trace.c | 3 + kernel/trace/trace.h | 11 ++ kernel/trace/trace_functions_hist.c | 345 ++++++++++++++++++++++++++++++++++++ 4 files changed, 360 insertions(+) create mode 100644 kernel/trace/trace_functions_hist.c
kernel/trace/Makefile +1 -0
@@ -34,6 +34,7 @@ obj-$(CONFIG_TRACING) += trace_printk.o obj-$(CONFIG_TRACING) += tracing_map.o obj-$(CONFIG_CONTEXT_SWITCH_TRACER) += trace_sched_switch.o obj-$(CONFIG_FUNCTION_TRACER) += trace_functions.o +obj-$(CONFIG_FUNCTION_TRACER) += trace_functions_hist.o obj-$(CONFIG_IRQSOFF_TRACER) += trace_irqsoff.o obj-$(CONFIG_PREEMPT_TRACER) += trace_irqsoff.o obj-$(CONFIG_SCHED_TRACER) += trace_sched_wakeup.o
kernel/trace/trace.c +3 -0
@@ -6729,6 +6729,9 @@ init_tracer_tracefs(struct trace_array *tr, struct dentry *d_tracer)if (ftrace_create_function_files (tr, d_tracer))WARN (1 ,"Could not allocate function filter files" ); +if (ftrace_create_function_hist_files (tr, d_tracer)) +WARN (1 ,"Could not allocate function_hist filter files" ); +#ifdef CONFIG_TRACER_SNAPSHOT trace_create_file ("snapshot" ,0644 , d_tracer, tr, &snapshot_fops);
kernel/trace/trace.h +11 -0
@@ -820,7 +820,10 @@ static inline int ftrace_trace_task(struct task_struct *task)extern int ftrace_is_dead (void );int ftrace_create_function_files (struct trace_array *tr,struct dentry *parent); +int ftrace_create_function_hist_files (struct trace_array *tr, +struct dentry *parent);void ftrace_destroy_function_files (struct trace_array *tr); +void ftrace_destroy_function_hist_files (struct trace_array *tr);void ftrace_init_global_array_ops (struct trace_array *tr);void ftrace_init_array_ops (struct trace_array *tr,ftrace_func_t func);void ftrace_reset_array_ops (struct trace_array *tr);
@@ -837,7 +840,15 @@ ftrace_create_function_files(struct trace_array *tr, {return 0 ; } +static inline int +ftrace_create_function_hist_files (struct trace_array *tr, +struct dentry *parent) +{ +return 0 ; +}static inline void ftrace_destroy_function_files (struct trace_array *tr) { } +static inline void +ftrace_destroy_function_hist_files (struct trace_array *tr) { }static inline __init void ftrace_init_global_array_ops (struct trace_array *tr) { }static inline void ftrace_reset_array_ops (struct trace_array *tr) { }
kernel/trace/trace_functions_hist.c new file +345 -0
345 lines not on this page · raw message
Signature · 1 line
1.9.3
PATCH v5 9/10 tracing: Add 'hist' trigger Documentation
In reply to Tom ZanussiAdd documentation and usage examples for 'hist' triggers.
--- Documentation/trace/events.txt | 872 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 872 insertions(+)
Documentation/trace/events.txt +872 -0
@@ -494,3 +494,875 @@ The following commands are supported: Note that there can be only one traceon or traceoff trigger per triggering event. + +- hist + + This command aggregates event hits into a hash table keyed on a + trace event format fields (or stacktrace) and a set of running + totals derived from one or more trace event format fields and/or + event counts (hitcount). + + The format of a hist trigger is as follows: + + hist:keys=<field1>[:values=<field1[,field2,...]] + [:size=#entries][:sort=field1][:pause][:continue] + [:clear] [if <filter>] + + When a matching event is hit, an entry is added to a hash table + using the key(s) and value(s) named. Keys and values correspond to + fields in the event's format description. Values must correspond to + numeric fields - on an event hit, the value(s) will be added to a + sum kept for that field. The special string 'hitcount' can be used + in place of an explicit value field - this is simply a count of + event hits. If 'values' isn't specified, an implicit 'hitcount' + value will be automatically created and used as the only value. + Keys can be any field, or the special string 'stacktrace', which + will use the event's kernel stacktrace as the key. The keywords + 'keys' or 'key' can be used to specify keys, and the keyworks + 'values', 'vals', or 'val' can be used to specify values. For the + time being, only a single key can be used - compound keys aren't yet + supported. + + 'hist' triggers add a 'hist' file to each event's subdirectory. + Reading the 'hist' file for the event will dump the hash table in + its entirety to stdout. By default, numeric fields are displayed as + base-10 integers. This can be modified by appending any of the + following modifiers to the field name: + + .hex display a number as a hex value + .sym display an address as a symbol + .syscall display a syscall id as a system call name + .execname display a common_pid as a program name + + A typical usage scenario would be the following to enable a hist + trigger, read its current contents, and then turn it off: + + # echo 'hist:keys=skbaddr.hex:vals=len' > \ + /sys/kernel/debug/tracing/events/net/netif_rx/trigger + + # cat /sys/kernel/debug/tracing/events/net/netif_rx/hist + + # echo '!hist:keys=skbaddr.hex:vals=len' > \ + /sys/kernel/debug/tracing/events/net/netif_rx/trigger + + The trigger file itself can be read to show the details of the + currently attached hist trigger. This information is also displayed + at the top of the 'hist' file when read. + + By default, the size of the hash table is 2048 entries. The 'size' + param can be used to specify more or fewer than that. The units are + in terms of hashtable entries - if a run uses more entries than + specified, the results will show the number of 'drops', the number + of hits that were ignored. The size should be a power of 2 between + 128 and 131072 (any non- power-of-2 number specified will be rounded + up). + + The 'sort' param can be used to specify a value field to sort on. + The default if unspecified is 'hitcount' and the default sort order + is 'ascending'. To sort in the opposite direction, append + .descending' to the sort key. + + The 'pause' param can be used to pause an existing hist trigger or + to start a hist trigger but not log any events until told to do so. + 'continue' or 'cont' can be used to start or restart a paused hist + trigger. + + The 'clear' param will clear the contents of a running hist trigger + and leave its current paused/active state. + +- enable_hist/disable_hist + + The enable_hist and disable_hist triggers can be used to have one + event conditionally start and stop another event's already-attached + hist trigger. Any number of enable_hist and disable_hist triggers + can be attached to a given event, allowing that event to kick off + and stop aggregations on a host of other events. + + The format is very similar to the enable/disable_event triggers: + + enable_hist:<system>:<event>[:count] + disable_hist:<system>:<event>[:count] + + Instead of enabling or disabling the tracing of the target event + into the trace buffer as the enable/disable_event triggers do, the + enable/disable_hist triggers enable or disable the aggregation of + the target event into a hash table. + + A typical usage scenario for the enable_hist/disable_hist triggers + would be to first set up a paused hist trigger on some event, + followed by an enable_hist/disable_hist pair that turns the hist + aggregation on and off when conditions of interest are hit: + + # echo 'hist:keys=skbaddr.hex:vals=len:pause' > \ + /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger + + # echo 'enable_hist:net:netif_receive_skb if filename==/usr/bin/wget' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_exec/trigger + + # echo 'disable_hist:net:netif_receive_skb if comm==wget' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_exit/trigger + + The above sets up an initially paused hist trigger which is unpaused + and starts aggregating events when a given program is executed, and + which stops aggregating when the process exits and the hist trigger + is paused again. + + The examples below provide a more concrete illustration of the + concepts and typical usage patterns discussed above. + + +6.2 'hist' trigger examples +--------------------------- + + The first set of examples creates aggregations using the kmalloc + event. The fields that can be used for the hist trigger are listed + in the kmalloc event's format file: + + # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/format + name: kmalloc + ID: 374 + format: + field:unsigned short common_type; offset:0; size:2; signed:0; + field:unsigned char common_flags; offset:2; size:1; signed:0; + field:unsigned char common_preempt_count; offset:3; size:1; signed:0; + field:int common_pid; offset:4; size:4; signed:1; + + field:unsigned long call_site; offset:8; size:8; signed:0; + field:const void * ptr; offset:16; size:8; signed:0; + field:size_t bytes_req; offset:24; size:8; signed:0; + field:size_t bytes_alloc; offset:32; size:8; signed:0; + field:gfp_t gfp_flags; offset:40; size:4; signed:0; + + We'll start by creating a hist trigger that generates a simple table + that lists the total number of bytes requested for each function in + the kernel that made one or more calls to kmalloc: + + # echo 'hist:key=call_site:val=bytes_req' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + + This tells the tracing system to create a 'hist' trigger using the + call_site field of the kmalloc event as the key for the table, which + just means that each unique call_site address will have an entry + created for it in the table. The 'val=bytes_req' parameter tells + the hist trigger that for each unique entry (call_site) in the + table, it should keep a running total of the number of bytes + requested by that call_site. + + We'll let it run for awhile and then dump the contents of the 'hist' + file in the kmalloc event's subdirectory (for readability, a number + of entries have been omitted): + + # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/hist + trigger info: hist:keys=call_site:vals=bytes_req:sort=hitcount:size=2048 [active] + + call_site: 18446744071581750326 hitcount: 1 bytes_req: 24 + call_site: 18446744071583151255 hitcount: 1 bytes_req: 32 + call_site: 18446744071582443167 hitcount: 1 bytes_req: 264 + call_site: 18446744072104099935 hitcount: 2 bytes_req: 464 + call_site: 18446744071579323550 hitcount: 3 bytes_req: 168 + call_site: 18446744071580558850 hitcount: 4 bytes_req: 65536 + . + . + . + call_site: 18446744072101362738 hitcount: 4115 bytes_req: 362120 + call_site: 18446744072103235682 hitcount: 4115 bytes_req: 427960 + call_site: 18446744072102962280 hitcount: 4342 bytes_req: 1637584 + call_site: 18446744072102962328 hitcount: 4973 bytes_req: 360624 + call_site: 18446744072101400062 hitcount: 6465 bytes_req: 258600 + call_site: 18446744071582063959 hitcount: 7818 bytes_req: 15636 + call_site: 18446744072102968908 hitcount: 9315 bytes_req: 8912400 + call_site: 18446744072103122419 hitcount: 9315 bytes_req: 819720 + call_site: 18446744072101402850 hitcount: 10240 bytes_req: 573440 + call_site: 18446744072099471334 hitcount: 23820 bytes_req: 476512 + + Totals: + Hits: 109976 + Entries: 76 + Dropped: 0 + + The output displays a line for each entry, beginning with the key + specified in the trigger, followed by the value(s) also specified in + the trigger. At the beginning of the output is a line that displays + the trigger info, which can also be displayed by reading the + 'trigger' file: + + # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + hist:keys=call_site:vals=bytes_req:sort=hitcount:size=2048 [active] + + At the end of the output are a few lines that display the overall + totals for the run. The 'Hits' field shows the total number of + times the event trigger was hit, the 'Entries' fields shows the + total number of used entries in the hash table, and the 'Dropped' + field shows the number of hits that were dropped because the number + of used entries for the run exceeded the maximum number of entries + allowed for the table (normally 0, but if not a hint that you may + want to increase the size of the table using the 'size' param). + + Notice in the above output that there's an extra field, 'hitcount', + that wasn't specified in the trigger. Also notice that in the + trigger info a param,'sort=hitcount', which wasn't specified in the + trigger either. The reason is that every trigger implicitly keeps a + count of the total number of hits attributed to a given entry, + called the 'hitcount', and that in the absence of a user-specified + sort param, the hitcount is used as the default sort field. + + The value 'hitcount' can be used in place of an explicit value in + the 'values' param if you don't really need to have any particular + field summed and are mainly interested in hit frequencies. + + To turn the hist trigger off, simply call up the trigger in command + history and re-execute it with a '!' prepended: + + # echo '!hist:key=call_site:val=bytes_req' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + + Finally, notice that the call_site as displayed in the output above + isn't really very useful. It's an address, but normally addresses + are displayed in hex. To have a numeric field displayed as hex + values, simply append '.hex' to the field name in the trigger: + + # echo 'hist:key=call_site.hex:val=bytes_req' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + + # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/hist + trigger info: hist:keys=call_site.hex:vals=bytes_req:sort=hitcount:size=2048 [active] + + call_site: ffffffffa04e85cb hitcount: 1 bytes_req: 511 + call_site: ffffffff810a66a9 hitcount: 1 bytes_req: 1024 + call_site: ffffffff8152db82 hitcount: 1 bytes_req: 8 + call_site: ffffffffa008829e hitcount: 1 bytes_req: 7 + call_site: ffffffffa0087d6a hitcount: 1 bytes_req: 7 + call_site: ffffffffa02eb7e1 hitcount: 1 bytes_req: 433 + call_site: ffffffff8152cbde hitcount: 1 bytes_req: 192 + call_site: ffffffff811a2602 hitcount: 2 bytes_req: 32768 + . + . + . + call_site: ffffffffa0419062 hitcount: 724 bytes_req: 75296 + call_site: ffffffffa024fc32 hitcount: 724 bytes_req: 63712 + call_site: ffffffffa03d6468 hitcount: 852 bytes_req: 416736 + call_site: ffffffffa03d6498 hitcount: 944 bytes_req: 70984 + call_site: ffffffff81311d57 hitcount: 961 bytes_req: 1922 + call_site: ffffffffa0258dfe hitcount: 1429 bytes_req: 57160 + call_site: ffffffffa03fd5f3 hitcount: 1796 bytes_req: 158048 + call_site: ffffffffa03d7e4c hitcount: 1796 bytes_req: 2206848 + call_site: ffffffffa02598e2 hitcount: 3196 bytes_req: 178976 + call_site: ffffffffa0081fe6 hitcount: 9529 bytes_req: 190584 + + Totals: + Hits: 24542 + Entries: 60 + Dropped: 0 + + Even that's only marginally more useful - while hex values do look + more like addresses, what users are typically more interested in + when looking at text addresses are the corresponding symbols + instead. To have an address displayed as symbolic value instead, + simply append '.sym' to the field name in the trigger: + + # echo 'hist:key=call_site.sym:val=bytes_req' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + + # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/hist + trigger info: hist:keys=call_site.sym:vals=bytes_req:sort=hitcount:size=2048 [active] + + call_site: [ffffffff8152db82] usb_control_msg hitcount: 1 bytes_req: 8 + call_site: [ffffffffa04e85cb] __ieee80211_start_scan hitcount: 1 bytes_req: 511 + call_site: [ffffffff815d7f6b] sk_prot_alloc hitcount: 1 bytes_req: 976 + call_site: [ffffffff8152cbde] usb_alloc_urb hitcount: 1 bytes_req: 192 + call_site: [ffffffff815d2c1b] sock_alloc_inode hitcount: 1 bytes_req: 64 + call_site: [ffffffffa02eb7e1] nl80211_trigger_scan hitcount: 1 bytes_req: 433 + call_site: [ffffffffa0087d6a] hidraw_report_event hitcount: 1 bytes_req: 7 + call_site: [ffffffff810a66a9] syslog_print_all hitcount: 1 bytes_req: 1024 + call_site: [ffffffffa008829e] hidraw_send_report hitcount: 1 bytes_req: 7 + call_site: [ffffffff811f1316] mounts_open_common hitcount: 2 bytes_req: 368 + call_site: [ffffffff811d0825] alloc_fdtable hitcount: 2 bytes_req: 96 + call_site: [ffffffffa042106f] __intel_framebuffer_create hitcount: 3 bytes_req: 432 + . + . + . + call_site: [ffffffff8136b079] sg_kmalloc hitcount: 461 bytes_req: 153696 + call_site: [ffffffffa03dbc5e] i915_gem_obj_lookup_or_create_vma hitcount: 462 bytes_req: 92400 + call_site: [ffffffffa03e213a] i915_gem_object_get_pages_gtt hitcount: 462 bytes_req: 7392 + call_site: [ffffffffa03d6498] i915_gem_do_execbuffer.isra.22 hitcount: 697 bytes_req: 52064 + call_site: [ffffffff81311d57] apparmor_file_alloc_security hitcount: 926 bytes_req: 1852 + call_site: [ffffffffa0258dfe] drm_vma_node_allow hitcount: 1050 bytes_req: 42000 + call_site: [ffffffffa03fd5f3] intel_ring_begin hitcount: 1116 bytes_req: 98208 + call_site: [ffffffffa03d7e4c] i915_gem_execbuffer2 hitcount: 1116 bytes_req: 956984 + call_site: [ffffffffa02598e2] drm_modeset_lock_crtc hitcount: 2055 bytes_req: 115080 + call_site: [ffffffffa0081fe6] hid_report_raw_event hitcount: 6433 bytes_req: 128664 + + Totals: + Hits: 17384 + Entries: 62 + Dropped: 0 + + Because the default sort key above is 'hitcount', the above shows a + the list of call_sites by increasing hitcount, so that at the bottom + we see the functions that made the most kmalloc calls during the + run. If instead we we wanted to see the top kmalloc callers in + terms of the number of bytes requested rather than the number of + calls, and we wanted the top caller to appear at the top, we can use + the 'sort' param, along with the 'descending' modifier: + + # echo 'hist:key=call_site.sym:val=bytes_req:sort=bytes_req.descending' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + + # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/hist + trigger info: hist:keys=call_site.sym:vals=bytes_req:sort=bytes_req:size=2048 [active] + + call_site: [ffffffffa03d7e4c] i915_gem_execbuffer2 hitcount: 682 bytes_req: 766360 + call_site: [ffffffff811d6c3b] seq_buf_alloc hitcount: 46 bytes_req: 186176 + call_site: [ffffffffa03d6468] i915_gem_do_execbuffer.isra.22 hitcount: 377 bytes_req: 142808 + call_site: [ffffffffa02598e2] drm_modeset_lock_crtc hitcount: 1107 bytes_req: 61992 + call_site: [ffffffffa03fd5f3] intel_ring_begin hitcount: 682 bytes_req: 60016 + call_site: [ffffffffa0081fe6] hid_report_raw_event hitcount: 2993 bytes_req: 59864 + call_site: [ffffffff8136b079] sg_kmalloc hitcount: 206 bytes_req: 48096 + call_site: [ffffffffa03dbc5e] i915_gem_obj_lookup_or_create_vma hitcount: 206 bytes_req: 41200 + call_site: [ffffffff811a2602] __kmalloc hitcount: 2 bytes_req: 32768 + call_site: [ffffffffa0419062] intel_crtc_page_flip hitcount: 305 bytes_req: 31720 + call_site: [ffffffffa024fc32] drm_mode_page_flip_ioctl hitcount: 305 bytes_req: 26840 + call_site: [ffffffffa0258dfe] drm_vma_node_allow hitcount: 603 bytes_req: 24120 + call_site: [ffffffffa03d6498] i915_gem_do_execbuffer.isra.22 hitcount: 305 bytes_req: 23072 + call_site: [ffffffff812775da] ext4_find_extent hitcount: 79 bytes_req: 7584 + . + . + . + call_site: [ffffffff811f3b07] inotify_handle_event hitcount: 2 bytes_req: 96 + call_site: [ffffffff811bfb6e] vfs_rename hitcount: 6 bytes_req: 66 + call_site: [ffffffff815d2c1b] sock_alloc_inode hitcount: 1 bytes_req: 64 + call_site: [ffffffff811d0825] alloc_fdtable hitcount: 1 bytes_req: 48 + call_site: [ffffffff81220376] proc_self_follow_link hitcount: 2 bytes_req: 24 + call_site: [ffffffff8112e1ec] hist_show hitcount: 2 bytes_req: 16 + call_site: [ffffffff8112e1d0] hist_show hitcount: 2 bytes_req: 16 + call_site: [ffffffff8152db82] usb_control_msg hitcount: 1 bytes_req: 8 + call_site: [ffffffffa008829e] hidraw_send_report hitcount: 1 bytes_req: 7 + call_site: [ffffffffa0087d6a] hidraw_report_event hitcount: 1 bytes_req: 7 + + Totals: + Hits: 9331 + Entries: 57 + Dropped: 0 + + We can also add multiple fields to the 'values' param. For example, + we might want to see the total number of bytes allocated alongside + bytes requested, and display the result sorted by bytes allocated in + a descending order: + + # echo 'hist:keys=call_site.sym:values=bytes_req,bytes_alloc:sort=bytes_alloc.descending' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + + # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/hist + trigger info: hist:keys=call_site.sym:vals=bytes_req,bytes_alloc:sort=bytes_alloc:size=2048 [active] + + call_site: [ffffffffa03d7e4c] i915_gem_execbuffer2 hitcount: 4427 bytes_req: 4190032 bytes_alloc: 5967744 + call_site: [ffffffff811d6c3b] seq_buf_alloc hitcount: 427 bytes_req: 1706768 bytes_alloc: 1765376 + call_site: [ffffffffa03d6468] i915_gem_do_execbuffer.isra.22 hitcount: 1978 bytes_req: 765936 bytes_alloc: 1434304 + call_site: [ffffffffa03fd5f3] intel_ring_begin hitcount: 4427 bytes_req: 389576 bytes_alloc: 424992 + call_site: [ffffffff8136b079] sg_kmalloc hitcount: 993 bytes_req: 305824 bytes_alloc: 376576 + call_site: [ffffffffa02598e2] drm_modeset_lock_crtc hitcount: 4319 bytes_req: 241864 bytes_alloc: 276416 + call_site: [ffffffffa03dbc5e] i915_gem_obj_lookup_or_create_vma hitcount: 993 bytes_req: 198600 bytes_alloc: 254208 + call_site: [ffffffffa0419062] intel_crtc_page_flip hitcount: 1806 bytes_req: 187824 bytes_alloc: 231168 + call_site: [ffffffff81424d78] __tty_buffer_request_room hitcount: 61 bytes_req: 128928 bytes_alloc: 229376 + call_site: [ffffffffa0081fe6] hid_report_raw_event hitcount: 9550 bytes_req: 191024 bytes_alloc: 210160 + call_site: [ffffffffa03d6498] i915_gem_do_execbuffer.isra.22 hitcount: 2449 bytes_req: 184720 bytes_alloc: 209216 + call_site: [ffffffffa0258dfe] drm_vma_node_allow hitcount: 3256 bytes_req: 130240 bytes_alloc: 208384 + . + . + . + call_site: [ffffffffa04e85cb] __ieee80211_start_scan hitcount: 3 bytes_req: 1533 bytes_alloc: 1536 + call_site: [ffffffffa02eb7e1] nl80211_trigger_scan hitcount: 3 bytes_req: 1299 bytes_alloc: 1536 + call_site: [ffffffff8152cbde] usb_alloc_urb hitcount: 6 bytes_req: 1152 bytes_alloc: 1152 + call_site: [ffffffff811f3b07] inotify_handle_event hitcount: 14 bytes_req: 744 bytes_alloc: 896 + call_site: [ffffffff81206b81] load_elf_binary hitcount: 24 bytes_req: 672 bytes_alloc: 768 + call_site: [ffffffff811bfb6e] vfs_rename hitcount: 38 bytes_req: 436 bytes_alloc: 640 + call_site: [ffffffff81220376] proc_self_follow_link hitcount: 24 bytes_req: 288 bytes_alloc: 384 + call_site: [ffffffff815d2c1b] sock_alloc_inode hitcount: 5 bytes_req: 320 bytes_alloc: 320 + call_site: [ffffffff811d0825] alloc_fdtable hitcount: 4 bytes_req: 192 bytes_alloc: 256 + call_site: [ffffffffa04ec05f] ieee80211_start_tx_ba_session hitcount: 1 bytes_req: 232 bytes_alloc: 256 + call_site: [ffffffffa0244701] drm_vm_open_locked hitcount: 5 bytes_req: 160 bytes_alloc: 160 + call_site: [ffffffff8112e1d0] hist_show hitcount: 10 bytes_req: 80 bytes_alloc: 80 + call_site: [ffffffff8112e1ec] hist_show hitcount: 10 bytes_req: 80 bytes_alloc: 80 + call_site: [ffffffff81074c9e] kthread_create_on_node hitcount: 1 bytes_req: 56 bytes_alloc: 64 + call_site: [ffffffff8152db82] usb_control_msg hitcount: 6 bytes_req: 48 bytes_alloc: 48 + call_site: [ffffffffa008829e] hidraw_send_report hitcount: 6 bytes_req: 42 bytes_alloc: 48 + call_site: [ffffffffa0087d6a] hidraw_report_event hitcount: 6 bytes_req: 42 bytes_alloc: 48 + + Totals: + Hits: 45576 + Entries: 66 + Dropped: 0 + + Finally, to finish off our kmalloc example, instead of simply having + the hist trigger display symbolic call_sites, we can have the hist + trigger additionally display the complete set of kernel stack traces + that led to each call_sites. To do that, we simply use the special + value 'stacktrace' for the key param: + + # echo 'hist:keys=stacktrace:values=bytes_req,bytes_alloc:sort=bytes_alloc' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + + The above trigger will use the kernel stack trace in effect when an + event is triggered as the key for the hash table. This allows the + enumeration of every kernel callpath that led up to a particular + event, along with a running total of any of the event fields for + that event. Here we tally bytes requested and bytes allocated for + every callpath in the system that led up to a kmalloc (in this case + every callpath to a kmalloc for a kernel compile): + + # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/hist + trigger info: hist:keys=stacktrace:vals=bytes_req,bytes_alloc:sort=bytes_alloc:size=2048 [active] + + stacktrace: + __kmalloc_track_caller+0x10b/0x190 + kstrdup+0x35/0x70 + __kernfs_new_node+0x34/0xf0 + kernfs_new_node+0x26/0x50 + kernfs_create_dir_ns+0x29/0x80 + sysfs_create_dir_ns+0x40/0xa0 + kobject_add_internal+0xbd/0x3a0 + kobject_add+0x60/0xb0 + device_add+0xff/0x5a0 + device_register+0x1e/0x30 + usb_create_ep_devs+0x81/0xd0 + usb_new_device+0x357/0x410 + hub_event+0xd68/0x11a0 + process_one_work+0x149/0x3d0 + worker_thread+0x121/0x4a0 + kthread+0xd2/0xf0 + hitcount: 1 bytes_req: 6 bytes_alloc: 8 + stacktrace: + kmem_cache_alloc_trace+0xfb/0x160 + usb_control_msg+0x42/0x110 + hub_port_status+0x84/0x120 + hub_port_reset+0x263/0x430 + hub_port_init+0x77/0xbb0 + hub_event+0x944/0x11a0 + process_one_work+0x149/0x3d0 + worker_thread+0x121/0x4a0 + kthread+0xd2/0xf0 + ret_from_fork+0x7c/0xb0 + hitcount: 1 bytes_req: 8 bytes_alloc: 8 + . + . + . + stacktrace: + __kmalloc+0x11b/0x1a0 + load_elf_phdrs+0x76/0xa0 + load_elf_binary+0x102/0x1780 + search_binary_handler+0x97/0x1d0 + do_execveat_common.isra.32+0x551/0x6e0 + SyS_execve+0x3a/0x50 + stub_execve+0x69/0xa0 + hitcount: 131791 bytes_req: 67822944 bytes_alloc: 80279552 + stacktrace: + __kmalloc+0x11b/0x1a0 + i915_gem_execbuffer2+0x6c/0x2c0 [i915] + drm_ioctl+0x1a4/0x630 [drm] + do_vfs_ioctl+0x2f0/0x4f0 + SyS_ioctl+0x81/0xa0 + system_call_fastpath+0x12/0x17 + hitcount: 164540 bytes_req: 134464456 bytes_alloc: 167693376 + stacktrace: + kmem_cache_alloc_trace+0xfb/0x160 + apparmor_file_alloc_security+0x27/0x40 + security_file_alloc+0x16/0x20 + get_empty_filp+0x93/0x1c0 + path_openat+0x31/0x620 + do_filp_open+0x3a/0x90 + do_sys_open+0x128/0x220 + SyS_open+0x1e/0x20 + system_call_fastpath+0x12/0x17 + hitcount: 22118413 bytes_req: 44236888 bytes_alloc: 176947328 + stacktrace: + __kmalloc+0x11b/0x1a0 + seq_buf_alloc+0x1b/0x50 + seq_read+0x2cc/0x370 + proc_reg_read+0x3d/0x80 + __vfs_read+0x18/0x50 + vfs_read+0x86/0x140 + SyS_read+0x46/0xb0 + system_call_fastpath+0x12/0x17 + hitcount: 66168 bytes_req: 271015944 bytes_alloc: 271015952 + + Totals: + Hits: 26780801 + Entries: 633 + Dropped: 0 + + If you key a hist trigger on pid, for example, to gather and display + sorted totals for each process, you can use the special .execname + modifier to display the executable names for the processes in the + table rather than raw pids. The example below keeps a per-process + sum of total bytes read: + + # echo 'hist:key=common_pid.execname:val=count:sort=count.descending' > \ + /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger + + # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/hist + trigger info: hist:keys=common_pid.execname:vals=count:sort=count:size=2048 [active] + + common_pid: Xorg [18446612132314219843] hitcount: 166 count: 159744 + common_pid: gnome-terminal [18446612132314221635] hitcount: 44 count: 113321 + common_pid: compiz [18446612132314221491] hitcount: 13 count: 81968 + common_pid: bash [18446612132314231931] hitcount: 3 count: 66369 + common_pid: gdbus [18446612132314221135] hitcount: 91 count: 1456 + common_pid: acpid [18446612132314219701] hitcount: 48 count: 1152 + common_pid: ibus-daemon [18446612132314221129] hitcount: 71 count: 1136 + common_pid: gdbus [18446612132314221638] hitcount: 42 count: 672 + common_pid: gdbus [18446612132314221345] hitcount: 42 count: 672 + common_pid: ibus-engine-sim [18446612132314221344] hitcount: 14 count: 224 + common_pid: gdbus [18446612132314221262] hitcount: 12 count: 192 + common_pid: gdbus [18446612132314221249] hitcount: 6 count: 96 + common_pid: ibus-ui-gtk3 [18446612132314221245] hitcount: 6 count: 96 + common_pid: gdbus [18446612132314221504] hitcount: 5 count: 80 + common_pid: unity-panel-ser [18446612132314221243] hitcount: 3 count: 48 + common_pid: postgres [18446612132314220339] hitcount: 1 count: 16 + common_pid: gdbus [18446612132314221395] hitcount: 1 count: 16 + common_pid: rtkit-daemon [18446612132314220509] hitcount: 1 count: 8 + common_pid: upstart-dbus-br [18446612132314221100] hitcount: 4 count: 4 + common_pid: bash [18446612132314221924] hitcount: 4 count: 4 + common_pid: firefox [18446612132314222258] hitcount: 1 count: 1 + + Totals: + Hits: 578 + Entries: 21 + Dropped: 0 + + + Similarly, if you key a hist trigger on syscall id, for example to + gather and display a list of systemwide syscall hits, you can use + the special .syscall modifier to display the syscall names rather + than raw ids. The example below keeps a running total of syscall + counts for the system during the run: + + # echo 'hist:key=id.syscall:val=hitcount' > \ + /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger + + # cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist + trigger info: hist:keys=id.syscall:vals=:sort=hitcount:size=2048 [active] + + id: sys_fadvise64 hitcount: 1 + id: sys_bind hitcount: 1 + id: sys_fsync hitcount: 1 + id: sys_getsockname hitcount: 1 + id: sys_readlink hitcount: 3 + id: sys_set_tid_address hitcount: 4 + . + . + . + id: sys_mprotect hitcount: 57 + id: sys_waitid hitcount: 64 + id: sys_rt_sigaction hitcount: 121 + id: sys_inotify_add_watch hitcount: 234 + id: sys_mmap hitcount: 258 + id: sys_nanosleep hitcount: 310 + id: sys_close hitcount: 323 + id: sys_rt_sigprocmask hitcount: 3520 + id: sys_futex hitcount: 4819 + id: sys_write hitcount: 8907 + id: sys_setitimer hitcount: 39039 + id: sys_writev hitcount: 64528 + id: sys_poll hitcount: 77493 + id: sys_recvmsg hitcount: 168240 + id: sys_ioctl hitcount: 448946 + + Totals: + Hits: 869971 + Entries: 75 + Dropped: 0 + + The next example uses a string field as the hash key and + demonstrates how you can manually pause and continue a hist trigger. + In this example, we'll aggregate fork counts and don't expect a + large number of entries in the hash table, so we'll drop it to a + much smaller number, say 256: + + # echo 'hist:key=child_comm:val=hitcount:size=256' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_fork/trigger + + # cat /sys/kernel/debug/tracing/events/sched/sched_process_fork/hist + trigger info: hist:keys=child_comm:vals=:sort=hitcount:size=256 [active] + + child_comm: gdbus hitcount: 1 + child_comm: smbd hitcount: 1 + child_comm: ibus-daemon hitcount: 1 + child_comm: Cache2 I/O hitcount: 1 + child_comm: dconf worker hitcount: 1 + child_comm: postgres hitcount: 1 + child_comm: unity-panel-ser hitcount: 2 + child_comm: compiz hitcount: 3 + child_comm: bash hitcount: 3 + child_comm: firefox hitcount: 60 + + Totals: + Hits: 74 + Entries: 10 + Dropped: 0 + + # echo 'hist:key=child_comm:val=hitcount:size=256:pause' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_fork/trigger + + If we want to pause the hist trigger, we can simply append :pause to + the command that started the trigger. Notice that the trigger info + displays as [paused]: + + # cat /sys/kernel/debug/tracing/events/sched/sched_process_fork/hist + trigger info: hist:keys=child_comm:vals=:sort=hitcount:size=256 [paused] + + child_comm: dconf worker hitcount: 1 + child_comm: gdbus hitcount: 1 + child_comm: Cache2 I/O hitcount: 1 + child_comm: ibus-daemon hitcount: 1 + child_comm: unity-panel-ser hitcount: 2 + child_comm: smbd hitcount: 2 + child_comm: postgres hitcount: 3 + child_comm: compiz hitcount: 3 + child_comm: bash hitcount: 3 + child_comm: emacs hitcount: 8 + child_comm: firefox hitcount: 60 + + Totals: + Hits: 85 + Entries: 11 + Dropped: 0 + + To manually continue having the trigger aggregate events, append + :cont instead. Notice that the trigger info displays as [active] + again, and the data has changed: + + # echo 'hist:key=child_comm:val=hitcount:size=256:cont' > + /sys/kernel/debug/tracing/events/sched/sched_process_fork/trigger + + # cat /sys/kernel/debug/tracing/events/sched/sched_process_fork/hist + trigger info: hist:keys=child_comm:vals=:sort=hitcount:size=256 [active] + + child_comm: Cache2 I/O hitcount: 1 + child_comm: ibus-daemon hitcount: 1 + child_comm: kthreadd hitcount: 1 + child_comm: gdbus hitcount: 1 + child_comm: dconf worker hitcount: 1 + child_comm: unity-panel-ser hitcount: 2 + child_comm: smbd hitcount: 2 + child_comm: compiz hitcount: 3 + child_comm: postgres hitcount: 4 + child_comm: bash hitcount: 4 + child_comm: emacs hitcount: 8 + child_comm: firefox hitcount: 60 + + Totals: + Hits: 88 + Entries: 12 + Dropped: 0 + + The previous example showed how to start and stop a hist trigger by + appending 'pause' and 'continue' to the hist trigger command. A + hist trigger can also be started in a paused state by initially + starting the trigger with ':pause' appended. This allows you to + start the trigger only when you're ready to start collecting data + and not before. For example, start the trigger in a paused state, + then unpause it and do something you want to measure, then pause the + trigger when done. + + Of course, doing this manually can be difficult and error-prone, but + it is possible to automatically start and stop a hist trigger based + on some condition, via the enable_hist and disable_hist triggers. + + For example, suppose we wanted to take a look at the relative + weights in terms of skb length for each callpath that leads to a + netif_receieve_skb event when downloading a decent-sized file using + wget. + + First we set up an initially paused stacktrace trigger on the + netif_receive_skb event: + + # echo 'hist:key=stacktrace:vals=len:pause' > \ + /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger + + Next, we set up an 'enable_hist' trigger on the sched_process_exec + event, with an 'if filename==/usr/bin/wget' filter. The effect of + this new trigger is that it will 'unpause' the hist trigger we just + set up on netif_receive_skb if and only if it sees a + sched_process_exec event with a filename of '/usr/bin/wget'. When + that happens, all netif_receive_skb events are aggregated into a + hash table keyed on stacktrace: + + # echo 'enable_hist:net:netif_receive_skb if filename==/usr/bin/wget' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_exec/trigger + + The aggregation continues until the netif_receive_skb is paused + again, which is what the following disable_hist event does by + creating a similar setup on the sched_process_exit event, using the + filter 'comm==wget': + + # echo 'disable_hist:net:netif_receive_skb if comm==wget' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_exit/trigger + + Whenever a process exits and the comm field of the disable_hist + trigger filter matches 'comm==wget', the netif_receive_skb hist + trigger is disabled. + + The overall effect is that netif_received_skb events are aggregated + into the hash table for only the duration of the wget. Executing a + wget command and then listing the 'hist' file will display the + output generated by the wget command: + + $ wget https://www.kernel.org/pub/linux/kernel/v3.x/patch-3.19.xz + + # cat /sys/kernel/debug/tracing/events/net/netif_receive_skb/hist + trigger info: hist:keys=stacktrace:vals=len:sort=hitcount:size=2048 [paused] + + stacktrace: + __netif_receive_skb_core+0x4ad/0x780 + __netif_receive_skb+0x18/0x60 + process_backlog+0xa8/0x150 + net_rx_action+0x15d/0x340 + __do_softirq+0x114/0x2c0 + do_softirq_own_stack+0x1c/0x30 + do_softirq+0x65/0x70 + __local_bh_enable_ip+0xb5/0xc0 + ip_finish_output+0x1f4/0x810 + ip_output+0x68/0xa0 + ip_local_out_sk+0x30/0x40 + ip_send_skb+0x1a/0x50 + udp_send_skb+0x173/0x2a0 + udp_sendmsg+0x2bf/0x9f0 + inet_sendmsg+0x63/0xb0 + do_sock_sendmsg+0x8c/0x100 + hitcount: 4 len: 388 + stacktrace: + __netif_receive_skb_core+0x4ad/0x780 + __netif_receive_skb+0x18/0x60 + netif_receive_skb_internal+0x23/0x90 + napi_gro_receive+0xc8/0x100 + ieee80211_deliver_skb+0xba/0x250 [mac80211] + ieee80211_rx_handlers+0xcc5/0x2240 [mac80211] + ieee80211_prepare_and_rx_handle+0x4e7/0xc30 [mac80211] + ieee80211_rx+0x31d/0x920 [mac80211] + iwlagn_rx_reply_rx+0x3db/0x6f0 [iwldvm] + iwl_rx_dispatch+0x8e/0xf0 [iwldvm] + iwl_pcie_irq_handler+0xe1c/0x12c0 [iwlwifi] + irq_thread_fn+0x20/0x50 + irq_thread+0x11f/0x150 + kthread+0xd2/0xf0 + ret_from_fork+0x7c/0xb0 + hitcount: 35 len: 17415 + stacktrace: + __netif_receive_skb_core+0x4ad/0x780 + __netif_receive_skb+0x18/0x60 + netif_receive_skb_internal+0x23/0x90 + napi_gro_complete+0xa4/0xe0 + dev_gro_receive+0x233/0x360 + napi_gro_receive+0x30/0x100 + ieee80211_deliver_skb+0xba/0x250 [mac80211] + ieee80211_rx_handlers+0xcc5/0x2240 [mac80211] + ieee80211_prepare_and_rx_handle+0x4e7/0xc30 [mac80211] + ieee80211_rx+0x31d/0x920 [mac80211] + iwlagn_rx_reply_rx+0x3db/0x6f0 [iwldvm] + iwl_rx_dispatch+0x8e/0xf0 [iwldvm] + iwl_pcie_irq_handler+0xe1c/0x12c0 [iwlwifi] + irq_thread_fn+0x20/0x50 + irq_thread+0x11f/0x150 + kthread+0xd2/0xf0 + hitcount: 155 len: 636342 + stacktrace: + __netif_receive_skb_core+0x4ad/0x780 + __netif_receive_skb+0x18/0x60 + netif_receive_skb_internal+0x23/0x90 + napi_gro_complete+0xa4/0xe0 + napi_gro_flush+0x6d/0x90 + iwl_pcie_irq_handler+0x90f/0x12c0 [iwlwifi] + irq_thread_fn+0x20/0x50 + irq_thread+0x11f/0x150 + kthread+0xd2/0xf0 + ret_from_fork+0x7c/0xb0 + hitcount: 1013 len: 5531908 + + Totals: + Hits: 1207 + Entries: 4 + Dropped: 0 + + The above shows all the netif_receive_skb callpaths and their total + lengths for the duration of the wget command. + + The 'clear' hist trigger param can be used to clear the hash table. + Suppose we wanted to try another run of the previous example but + this time also wanted to see the complete list of events that went + into the histogram. In order to avoid having to set everything up + again, we can just clear the histogram first: + + # echo 'hist:key=stacktrace:vals=len:clear' > \ + /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger + + Just to verify that it is in fact cleared, here's what we now see in + the hist file: + + # cat /sys/kernel/debug/tracing/events/net/netif_receive_skb/hist + trigger info: hist:keys=stacktrace:vals=len:sort=hitcount:size=2048 [paused] + + Totals: + Hits: 0 + Entries: 0 + Dropped: 0 + + Since we want to see the detailed list of every netif_receive_skb + event occurring during the new run, which are in fact same events + being aggregated into the hash table, we add some additional + 'enable_event' events the triggering sched_process_exec and + sched_process_exit events as such: + + # echo 'enable_event:net:netif_receive_skb if filename==/usr/bin/wget' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_exec/trigger + + # echo 'disable_event:net:netif_receive_skb if comm==wget' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_exit/trigger + + If you read the trigger files for the sched_process_exec and + sched_process_exit triggers, you should see two triggers for each: + one enabling/disabling the hist aggregation and the other + enabling/disabling the logging of events: + + # cat /sys/kernel/debug/tracing/events/sched/sched_process_exec/trigger + enable_event:net:netif_receive_skb:unlimited if filename==/usr/bin/wget + enable_hist:net:netif_receive_skb:unlimited if filename==/usr/bin/wget + + # cat /sys/kernel/debug/tracing/events/sched/sched_process_exit/trigger + enable_event:net:netif_receive_skb:unlimited if comm==wget + disable_hist:net:netif_receive_skb:unlimited if comm==wget + + In other words, whever either of the sched_process_exec or + sched_process_exit events is hit and matches 'wget', it enables or + disables both the histogram and the event log, and what you end up + with is a hash table and set of events just covering the specified + duration. + + Displaying the 'hist' file should show something similar to what you + saw in the last run, but this time you should also see the + individual events in the trace file: + + # cat /sys/kernel/debug/tracing/trace + # tracer: nop + # + # entries-in-buffer/entries-written: 183/1426 #P:4 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + wget-15108 [000] ..s1 31769.606929: netif_receive_skb: dev=lo skbaddr=ffff88009c353100 len=60 + wget-15108 [000] ..s1 31769.606999: netif_receive_skb: dev=lo skbaddr=ffff88009c353200 len=60 + dnsmasq-1382 [000] ..s1 31769.677652: netif_receive_skb: dev=lo skbaddr=ffff88009c352b00 len=130 + dnsmasq-1382 [000] ..s1 31769.685917: netif_receive_skb: dev=lo skbaddr=ffff88009c352200 len=138 + ##### CPU 2 buffer started #### + irq/29-iwlwifi-559 [002] ..s. 31772.031529: netif_receive_skb: dev=wlan0 skbaddr=ffff88009d433d00 len=2948 + irq/29-iwlwifi-559 [002] ..s. 31772.031572: netif_receive_skb: dev=wlan0 skbaddr=ffff88009d432200 len=1500 + irq/29-iwlwifi-559 [002] ..s. 31772.032196: netif_receive_skb: dev=wlan0 skbaddr=ffff88009d433100 len=2948 + irq/29-iwlwifi-559 [002] ..s. 31772.032761: netif_receive_skb: dev=wlan0 skbaddr=ffff88009d433000 len=2948 + irq/29-iwlwifi-559 [002] ..s. 31772.033220: netif_receive_skb: dev=wlan0 skbaddr=ffff88009d432e00 len=1500 + . + . + .
Signature · 1 line
1.9.3
PATCH v5 3/10 tracing: Add event record param to trigger_ops.func()
In reply to Tom ZanussiSome triggers may need access to the trace event, so pass it in. Also fix up the existing trigger funcs and their callers.
--- include/linux/ftrace_event.h | 7 ++++--- kernel/trace/trace.h | 6 ++++-- kernel/trace/trace_events_trigger.c | 35 ++++++++++++++++++----------------- 3 files changed, 26 insertions(+), 22 deletions(-)
include/linux/ftrace_event.h +4 -3
@@ -423,7 +423,8 @@ extern int call_filter_check_discard(struct ftrace_event_call *call, void *rec,extern enum event_trigger_type event_triggers_call (struct ftrace_event_file *file,void *rec);extern void event_triggers_post_call (struct ftrace_event_file *file, -enum event_trigger_type tt); +enum event_trigger_type tt, +void *rec);/** * ftrace_trigger_soft_disabled - do triggers and test if soft disabled
@@ -506,7 +507,7 @@ event_trigger_unlock_commit(struct ftrace_event_file *file,trace_buffer_unlock_commit (buffer, event, irq_flags, pc);if (tt) -event_triggers_post_call (file, tt); +event_triggers_post_call (file, tt, entry); }/**
@@ -539,7 +540,7 @@ event_trigger_unlock_commit_regs(struct ftrace_event_file *file, irq_flags, pc, regs);if (tt) -event_triggers_post_call (file, tt); +event_triggers_post_call (file, tt, entry); }#ifdef CONFIG_BPF_SYSCALL
kernel/trace/trace.h +4 -2
@@ -1125,7 +1125,8 @@ struct event_trigger_data {* @func: The trigger 'probe' function called when the triggering * event occurs. The data passed into this callback is the data * that was supplied to the event_command @reg() function that -* registered the trigger (see struct event_command). +* registered the trigger (see struct event_command) along with +* the trace record, rec. * * @init: An optional initialization function called for the trigger * when the trigger is registered (via the event_command reg()
@@ -1150,7 +1151,8 @@ struct event_trigger_data {* (see trace_event_triggers.c). */ struct event_trigger_ops { -void (*func)(struct event_trigger_data *data); +void (*func)(struct event_trigger_data *data, +void *rec);int (*init)(struct event_trigger_ops *ops,struct event_trigger_data *data); void (*free)(struct event_trigger_ops *ops,
kernel/trace/trace_events_trigger.c +18 -17
@@ -74,7 +74,7 @@ event_triggers_call(struct ftrace_event_file *file, void *rec)list_for_each_entry_rcu (data, &file->triggers, list) {if (!rec) { - data->ops->func (data); + data->ops->func (data, rec);continue ; } filter =rcu_dereference_sched (data->filter);
@@ -84,7 +84,7 @@ event_triggers_call(struct ftrace_event_file *file, void *rec) tt |= data->cmd_ops->trigger_type;continue ; } - data->ops->func (data); + data->ops->func (data, rec); }return tt; }
@@ -104,13 +104,14 @@ EXPORT_SYMBOL_GPL(event_triggers_call);*/ void event_triggers_post_call (struct ftrace_event_file *file, -enum event_trigger_type tt) +enum event_trigger_type tt, +void *rec) {struct event_trigger_data *data;list_for_each_entry_rcu (data, &file->triggers, list) {if (data->cmd_ops->trigger_type & tt) - data->ops->func (data); + data->ops->func (data, rec); } }EXPORT_SYMBOL_GPL (event_triggers_post_call);
@@ -752,7 +753,7 @@ static int set_trigger_filter(char *filter_str, }static void -traceon_trigger (struct event_trigger_data *data) +traceon_trigger (struct event_trigger_data *data,void *rec) {if (tracing_is_on ())return ;
@@ -761,7 +762,7 @@ traceon_trigger(struct event_trigger_data *data) }static void -traceon_count_trigger (struct event_trigger_data *data) +traceon_count_trigger (struct event_trigger_data *data,void *rec) {if (tracing_is_on ())return ;
@@ -776,7 +777,7 @@ traceon_count_trigger(struct event_trigger_data *data) }static void -traceoff_trigger (struct event_trigger_data *data) +traceoff_trigger (struct event_trigger_data *data,void *rec) {if (!tracing_is_on ())return ;
@@ -785,7 +786,7 @@ traceoff_trigger(struct event_trigger_data *data) }static void -traceoff_count_trigger (struct event_trigger_data *data) +traceoff_count_trigger (struct event_trigger_data *data,void *rec) {if (!tracing_is_on ())return ;
@@ -881,13 +882,13 @@ static struct event_command trigger_traceoff_cmd = {#ifdef CONFIG_TRACER_SNAPSHOT static void -snapshot_trigger (struct event_trigger_data *data) +snapshot_trigger (struct event_trigger_data *data,void *rec) {tracing_snapshot (); }static void -snapshot_count_trigger (struct event_trigger_data *data) +snapshot_count_trigger (struct event_trigger_data *data,void *rec) {if (!data->count)return ;
@@ -895,7 +896,7 @@ snapshot_count_trigger(struct event_trigger_data *data)if (data->count !=-1 ) (data->count)--; -snapshot_trigger (data); +snapshot_trigger (data, rec); } static int
@@ -974,13 +975,13 @@ static __init int register_trigger_snapshot_cmd(void) { return 0; }#define STACK_SKIP 3static void -stacktrace_trigger (struct event_trigger_data *data) +stacktrace_trigger (struct event_trigger_data *data,void *rec) {trace_dump_stack (STACK_SKIP ); }static void -stacktrace_count_trigger (struct event_trigger_data *data) +stacktrace_count_trigger (struct event_trigger_data *data,void *rec) {if (!data->count)return ;
@@ -988,7 +989,7 @@ stacktrace_count_trigger(struct event_trigger_data *data)if (data->count !=-1 ) (data->count)--; -stacktrace_trigger (data); +stacktrace_trigger (data, rec); } static int
@@ -1059,7 +1060,7 @@ struct enable_trigger_data { };static void -event_enable_trigger (struct event_trigger_data *data) +event_enable_trigger (struct event_trigger_data *data,void *rec) {struct enable_trigger_data *enable_data = data->private_data;
@@ -1070,7 +1071,7 @@ event_enable_trigger(struct event_trigger_data *data) }static void -event_enable_count_trigger (struct event_trigger_data *data) +event_enable_count_trigger (struct event_trigger_data *data,void *rec) {struct enable_trigger_data *enable_data = data->private_data;
@@ -1084,7 +1085,7 @@ event_enable_count_trigger(struct event_trigger_data *data)if (data->count !=-1 ) (data->count)--; -event_enable_trigger (data); +event_enable_trigger (data, rec); } static int
Signature · 1 line
1.9.3
PATCH v5 2/10 tracing: Make ftrace_event_field checking functions available
In reply to Tom ZanussiMake is_string_field() and is_function_field() accessible outside of trace_event_filters.c for other users of ftrace_event_fields.
--- kernel/trace/trace.h | 12 ++++++++++++ kernel/trace/trace_events_filter.c | 12 ------------ 2 files changed, 12 insertions(+), 12 deletions(-)
kernel/trace/trace.h +12 -0
@@ -1050,6 +1050,18 @@ struct filter_pred {unsigned short right; }; +static inline bool is_string_field (struct ftrace_event_field *field) +{ +return field->filter_type ==FILTER_DYN_STRING || + field->filter_type ==FILTER_STATIC_STRING || + field->filter_type ==FILTER_PTR_STRING ; +} + +static inline bool is_function_field (struct ftrace_event_field *field) +{ +return field->filter_type ==FILTER_TRACE_FN ; +} +extern enum regex_type filter_parse_regex (char *buff,int len,char **search,int *not); extern void print_event_filter(struct ftrace_event_file *file,
kernel/trace/trace_events_filter.c +0 -12
@@ -917,18 +917,6 @@ int filter_assign_type(const char *type)return FILTER_OTHER ; } -static bool is_function_field (struct ftrace_event_field *field) -{ -return field->filter_type ==FILTER_TRACE_FN ; -} - -static bool is_string_field (struct ftrace_event_field *field) -{ -return field->filter_type ==FILTER_DYN_STRING || - field->filter_type ==FILTER_STATIC_STRING || - field->filter_type ==FILTER_PTR_STRING ; -} -static int is_legal_op (struct ftrace_event_field *field,int op) { if (is_string_field(field) &&
Signature · 1 line
1.9.3
PATCH v5 8/10 tracing: Add enable_hist/disable_hist triggers
In reply to Tom ZanussiSimilar to enable_event/disable_event triggers, these triggers enable and disable the aggregation of events into maps rather than enabling and disabling their writing into the trace buffer.
They can be used to automatically start and stop hist triggers based on a matching filter condition.
If there's a paused hist trigger on system:event, the following would start it when the filter condition was hit:
# echo enable_hist:system:event [ if filter] > event/trigger
And the following would disable a running system:event hist trigger:
# echo disable_hist:system:event [ if filter] > event/trigger
See Documentation/trace/events.txt for real examples.
--- include/linux/ftrace_event.h | 1 + kernel/trace/trace.c | 11 ++++ kernel/trace/trace.h | 32 ++++++++++ kernel/trace/trace_events_hist.c | 115 ++++++++++++++++++++++++++++++++++++ kernel/trace/trace_events_trigger.c | 71 ++++++++++++---------- 5 files changed, 199 insertions(+), 31 deletions(-)
include/linux/ftrace_event.h +1 -0
@@ -411,6 +411,7 @@ enum event_trigger_type {ETT_STACKTRACE = (1 <<2 ),ETT_EVENT_ENABLE = (1 <<3 ),ETT_EVENT_HIST = (1 <<4 ), + ETT_HIST_ENABLE = (1 << 5), };extern int filter_match_preds (struct event_filter *filter,void *rec);
kernel/trace/trace.c +11 -0
@@ -3761,6 +3761,10 @@ static const char readme_msg[] = "\t trigger: traceon, traceoff\n" "\t enable_event:<system>:<event>\n" "\t disable_event:<system>:<event>\n" +#ifdef CONFIG_HIST_TRIGGERS + "\t enable_hist:<system>:<event>\n" + "\t disable_hist:<system>:<event>\n" +#endif#ifdef CONFIG_STACKTRACE "\t\t stacktrace\n"#endif
@@ -3825,6 +3829,13 @@ static const char readme_msg[] ="\t restart a paused hist trigger.\n\n" "\t The 'clear' param will clear the contents of a running hist\n" "\t trigger and leave its current paused/active state.\n\n" +"\t The enable_hist and disable_hist triggers can be used to\n" +"\t have one event conditionally start and stop another event's\n" +"\t already-attached hist trigger. Any number of enable_hist\n" +"\t and disable_hist triggers can be attached to a given event,\n" +"\t allowing that event to kick off and stop aggregations on\n" +"\t a host of other events. See Documentation/trace/events.txt\n" + "\t for examples.\n"#endif ;
kernel/trace/trace.h +32 -0
@@ -1102,8 +1102,10 @@ extern const struct file_operations event_hist_fops;#ifdef CONFIG_HIST_TRIGGERS extern int register_trigger_hist_cmd (void ); +extern int register_trigger_hist_enable_disable_cmds (void );#else static inline int register_trigger_hist_cmd (void ) {return 0 ; } +static inline int register_trigger_hist_enable_disable_cmds (void ) {return 0 ; }#endif extern int register_trigger_cmds (void );
@@ -1121,6 +1123,34 @@ struct event_trigger_data {struct list_head list; }; +/* Avoid typos */ +#define ENABLE_EVENT_STR "enable_event" +#define DISABLE_EVENT_STR "disable_event" +#define ENABLE_HIST_STR "enable_hist" +#define DISABLE_HIST_STR "disable_hist" + +struct enable_trigger_data { +struct ftrace_event_file *file; +bool enable; +bool hist; +}; + +extern int event_enable_trigger_print (struct seq_file *m, +struct event_trigger_ops *ops, +struct event_trigger_data *data); +extern void event_enable_trigger_free (struct event_trigger_ops *ops, +struct event_trigger_data *data); +extern int event_enable_trigger_func (struct event_command *cmd_ops, +struct ftrace_event_file *file, +char *glob,char *cmd,char *param); +extern int event_enable_register_trigger (char *glob, +struct event_trigger_ops *ops, +struct event_trigger_data *data, +struct ftrace_event_file *file); +extern void event_enable_unregister_trigger (char *glob, +struct event_trigger_ops *ops, +struct event_trigger_data *test, +struct ftrace_event_file *file);extern void trigger_data_free (struct event_trigger_data *data);extern int event_trigger_init (struct event_trigger_ops *ops,struct event_trigger_data *data);
@@ -1134,6 +1164,8 @@ extern int set_trigger_filter(char *filter_str,struct event_trigger_data *trigger_data, struct ftrace_event_file *file);extern int register_event_command (struct event_command *cmd); +extern int unregister_event_command (struct event_command *cmd); +extern int register_trigger_hist_enable_disable_cmds (void );/** * struct event_trigger_ops - callbacks for trace event triggers
kernel/trace/trace_events_hist.c +115 -0
118 lines not on this page · raw message
kernel/trace/trace_events_trigger.c +40 -31
161 lines not on this page · raw message
Signature · 1 line
1.9.3
v5 cover tracing: 'hist' triggers
This is v5 of the 'hist triggers' patchset, following feedback from v4.
Changes from v4:
This version addresses some problems and suggestions made by Daniel Wagner - a lot of the code was reworked to get rid of the distinction between keys and values, and as a result, both keys and values can be used as sort keys. As suggested, it also allows 'val=' to be absent in a trigger command - if no 'val' is specified, hitcount is assumed and automatically used as the only val.
The map code was also separated out into a separate file, tracing_map.c, allowing it to be reused. It also adds a second tracer called function_hist that actually does reuse the code, as an RFC patch.
Patch 01/10 [tracing: Update cond flag when enabling or disabling..] is a fix for a problem noticed by Daniel and that fixes a problem in existing trigger code and should be applied regardless of whether the rest of the patchset is merged.
As mentioned, patch 10/10 is an RFC patch implementing a new tracer based on the function tracer code. It's a fun little tool and is useful for a specific problem I'm working on (and is also a nice test of the tracing_map code), but is an RFC because first, I'm not sure it would really be of general interest and secondly, it's POC-level quality and I'd need to spend more time fixing it up to make it upstreamable, but I don't want to waste my time if not.
There are a couple of important bits of functionality that were present in v1 but not yet reimplemented in v5.
The first is support for compound keys. Currently, maps can only be keyed on a single event field, whereas in v1 they could be keyed on multiple keys. With support for compound keys, you can create much more interesting output, such as for example per-pid lists of syscalls or read counts e.g.:
# echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount' > \
/sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger# cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist
key: common_pid:bash[3112], id:sys_write vals: count:69
key: common_pid:bash[3112], id:sys_rt_sigprocmask vals: count:218
key: common_pid:update-notifier[3164], id:sys_poll vals: count:37
key: common_pid:update-notifier[3164], id:sys_recvfrom vals: count:118
key: common_pid:deja-dup-monito[3194], id:sys_sendto vals: count:1
key: common_pid:deja-dup-monito[3194], id:sys_read vals: count:4
key: common_pid:deja-dup-monito[3194], id:sys_poll vals: count:8
key: common_pid:deja-dup-monito[3194], id:sys_recvmsg vals: count:8
key: common_pid:deja-dup-monito[3194], id:sys_getegid vals: count:8
key: common_pid:emacs[3275], id:sys_fsync vals: count:1
key: common_pid:emacs[3275], id:sys_open vals: count:1
key: common_pid:emacs[3275], id:sys_symlink vals: count:2
key: common_pid:emacs[3275], id:sys_poll vals: count:23
key: common_pid:emacs[3275], id:sys_select vals: count:23
key: common_pid:emacs[3275], id:unknown_syscall vals: count:34
key: common_pid:emacs[3275], id:sys_ioctl vals: count:60
key: common_pid:emacs[3275], id:sys_rt_sigprocmask vals: count:116
key: common_pid:cat[3323], id:sys_munmap vals: count:1
key: common_pid:cat[3323], id:sys_fadvise64 vals: count:1
Related to that is support for sorting on multiple fields. Currently, you can sort using only a primary key. Being able to sort on multiple or at least a secondary key is indispensible for seeing trends when displaying multiple values.
Changes from v3:
v4 fixes the race in tracing_map_insert() noted in v3, where map.val.key could be checked even if map.val wasn't yet set. The simple fix for that in tracing_map_insert() introduces the possibility of duplicates in the map, which though rare, need to be accounted for in the output. To address that, duplicate-merging code was added to the map-printing code.
It was also pointed out that it didn't seem correct to include module.h, but the fix for that has deeper roots and is being addressed by a separate patchset; for now we need to continue including module.h, though prompted by that I did some other header include cleanup.
The functionality remains the same as v2, but this version no longer tries to export and use bpf_maps, and more importantly removes the associated GFP_NOTRACE/trace event hacks and kmem macros required to work around the bpf_map implementation.
The tracing_map functionality is instead built on top of a simple lock-free map algorithm originated by Dr. Cliff Click (see references in the code for more details), which though too restrictive to be general-purpose in its current form, functions nicely as a special-purpose tracing map.
v3 also moves the hist triggers code into a separate file and puts it all behind a new config option, CONFIG_HIST_TRIGGERS. It also merges in the sorting code rather than keeping it as a separate patch.
This patchset also includes a couple other new and related triggers, enable_hist and disable_hist, very similar to the existing enable_event/disable_event triggers used to automatically enable and disable events based on a triggering condition, but in this case allowing hist triggers to be enabled and disabled in the same way.
- Added an insert check for val before checking the key associated with val
- Added code to merge possible duplicates in the map
Changes from v2:
- reimplemented tracing_map, replacing bpf_map with nmi-safe/lock-free map
- removed GPF_NOTRACE, kmalloc/free macros and event hacks needed by bpf_maps
- moved hist triggers from trace_events_trigger.c to trace_events_hist.c
- added CONFIG_HIST_TRIGGERS config option
- consolidated sorting code with main patch
Changes from v1:
- completely rewritten on top of tracing_map (renamed and exported bpf_map)
- added map clearing and client ops to tracing_map
- changed the name from 'hash' triggers to 'hist' triggers
- added new trigger 'pause' feature
- added new enable_hist and disable_hist triggers
- added usage for hist/enable_hist/disable hist to tracing/README
- moved examples into Documentation/trace/event.txt
- added ___GFP_NOTRACE, kmalloc/kfree macros, and conditional kmem tracepoints
The following changes since commit f267caab44451baa70d25fa3191a68bb79ad1b08:
tracing: Remove unused prototype ftrace_event_define_field() (2015-05-13 14:03:51 -0400)
are available in the git repository at:
git://git.yoctoproject.org/linux-yocto-contrib.git tzanussi/hist-triggers-v5
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=tzanussi/hist-triggers-v5
Tom Zanussi (10):
tracing: Update cond flag when enabling or disabling a trigger
tracing: Make ftrace_event_field checking functions available
tracing: Add event record param to trigger_ops.func()
tracing: Add get_syscall_name()
tracing: Add a per-event-trigger 'paused' field
trace: Add lock-free tracing_map
tracing: Add 'hist' event trigger command
tracing: Add enable_hist/disable_hist triggers
tracing: Add 'hist' trigger Documentation
ftrace: Add function_hist tracer
Documentation/trace/events.txt | 872 ++++++++++++++++++++++++ include/linux/ftrace_event.h | 9 +- kernel/trace/Kconfig | 14 + kernel/trace/Makefile | 3 + kernel/trace/trace.c | 58 ++ kernel/trace/trace.h | 88 ++- kernel/trace/trace_events.c | 4 + kernel/trace/trace_events_filter.c | 12 - kernel/trace/trace_events_hist.c | 1238 +++++++++++++++++++++++++++++++++++ kernel/trace/trace_events_trigger.c | 149 +++-- kernel/trace/trace_functions_hist.c | 345 ++++++++++ kernel/trace/trace_syscalls.c | 11 + kernel/trace/tracing_map.c | 831 +++++++++++++++++++++++ kernel/trace/tracing_map.h | 133 ++++ 14 files changed, 3683 insertions(+), 84 deletions(-) create mode 100644 kernel/trace/trace_events_hist.c create mode 100644 kernel/trace/trace_functions_hist.c create mode 100644 kernel/trace/tracing_map.c create mode 100644 kernel/trace/tracing_map.h
Signature · 1 line
1.9.3
PATCH v5 6/10 trace: Add lock-free tracing_map
Add tracing_map, a special-purpose lock-free map for tracing.
tracing_map is designed to aggregate or 'sum' one or more values associated with a specific object of type tracing_map_elt, which is associated by the map to a given key.
It provides various hooks allowing per-tracer customization and is separated out into a separate file in order to allow it to be shared between multiple tracers, but isn't meant to be generally used outside of that context.
The tracing_map implementation was inspired by lock-free map algorithms originated by Dr. Cliff Click:
http://www.azulsystems.com/blog/cliff/2007-03-26-non-blocking-hashtable
http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf
--- kernel/trace/Makefile | 1 + kernel/trace/tracing_map.c | 831 +++++++++++++++++++++++++++++++++++++++++++++ kernel/trace/tracing_map.h | 133 ++++++++ 3 files changed, 965 insertions(+) create mode 100644 kernel/trace/tracing_map.c create mode 100644 kernel/trace/tracing_map.h
kernel/trace/Makefile +1 -0
@@ -31,6 +31,7 @@ obj-$(CONFIG_TRACING) += trace_output.o obj-$(CONFIG_TRACING) += trace_seq.o obj-$(CONFIG_TRACING) += trace_stat.o obj-$(CONFIG_TRACING) += trace_printk.o +obj-$(CONFIG_TRACING) += tracing_map.o obj-$(CONFIG_CONTEXT_SWITCH_TRACER) += trace_sched_switch.o obj-$(CONFIG_FUNCTION_TRACER) += trace_functions.o obj-$(CONFIG_IRQSOFF_TRACER) += trace_irqsoff.o
kernel/trace/tracing_map.c new file +831 -0
831 lines not on this page · raw message
kernel/trace/tracing_map.h new file +133 -0
133 lines not on this page · raw message
Signature · 1 line
1.9.3
Re: [PATCH 01/10] tracing: Update cond flag when enabling or disabling a trigger
In reply to Tom ZanussiQuoted 9 lines · Tom Zanussi
When a trigger is enabled, the cond flag should be set beforehand, otherwise a trigger that's expecting to process a trace record (e.g. one with
post_triggerset) could be invoked without one.Likewise a trigger's cond flag should be reset after it's disabled, not before.
Signed-off-by Tom Zanussi <[email protected]>Signed-off-by Daniel Wagner <[email protected]>
Thank you!
Quoted 57 lines
--- kernel/trace/trace_events_trigger.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)kernel/trace/trace_events_trigger.c +6
-4@@ -543,11 +543,12 @@ static int register_trigger(char *glob, struct event_trigger_ops *ops,list_add_rcu (&data->list, &file->triggers); ret++; +update_cond_flag (file);if (trace_event_trigger_enable_disable (file,1 ) <0 ) {list_del_rcu (&data->list); +update_cond_flag (file); ret--; } -update_cond_flag (file); out:return ret; }@@ -575,8 +576,8 @@ static void unregister_trigger(char *glob, struct event_trigger_ops *ops,if (data->cmd_ops->trigger_type == test->cmd_ops->trigger_type) { unregistered = true;list_del_rcu (&data->list); -update_cond_flag (file);trace_event_trigger_enable_disable (file,0 ); +update_cond_flag (file);break ; } }@@ -1319,11 +1320,12 @@ static int event_enable_register_trigger(char *glob,list_add_rcu (&data->list, &file->triggers); ret++; +update_cond_flag (file);if (trace_event_trigger_enable_disable (file,1 ) <0 ) {list_del_rcu (&data->list); +update_cond_flag (file); ret--; } -update_cond_flag (file); out:return ret; }@@ -1344,8 +1346,8 @@ static void event_enable_unregister_trigger(char *glob, (enable_data->file == test_enable_data->file)) { unregistered = true;list_del_rcu (&data->list); -update_cond_flag (file);trace_event_trigger_enable_disable (file,0 ); +update_cond_flag (file);break ; } }
Signature · 5 lines
Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research & Development Group E-mail: [email protected]
Hi Tom,
Quoted 11 lines · Tom Zanussi
This is v5 of the 'hist triggers' patchset, following feedback from v4.
Changes from v4:
This version addresses some problems and suggestions made by Daniel Wagner - a lot of the code was reworked to get rid of the distinction between keys and values, and as a result, both keys and values can be used as sort keys. As suggested, it also allows 'val=' to be absent in a trigger command - if no 'val' is specified, hitcount is assumed and automatically used as the only val.
Thank you for this amazing work! :)
Here is an example how I've used it.
---------
[root@localhost perf]# ./perf probe -a '__kmalloc caller=$stack0 size' Added new event:
probe:__kmalloc (on __kmalloc with caller=$stack0 size)
You can now use it in all perf tools, such as:
perf record -e probe:__kmalloc -aR sleep 1
[root@localhost perf]# cd /sys/kernel/debug/tracing
[root@localhost tracing]# echo hist:keys=caller.sym > events/probe/__kmalloc/trigger [root@localhost tracing]# echo 1 > events/probe/__kmalloc/enable [root@localhost tracing]# cat events/probe/__kmalloc/hist
# trigger info: hist:keys=caller.sym:vals=hitcount:sort=hitcount:size=2048 [active]
caller: [ffffffff811964d7] tracing_map_sort_entries hitcount: 1
caller: [ffffffff81296120] load_elf_binary hitcount: 1
caller: [ffffffff813eb98c] context_struct_to_string hitcount: 1
caller: [ffffffff81264c8c] simple_xattr_alloc hitcount: 1
caller: [ffffffff811e0a02] shmem_initxattrs hitcount: 1
caller: [ffffffff81295eb6] load_elf_phdrs hitcount: 2
caller: [ffffffff8169c49b] sk_prot_alloc hitcount: 2
caller: [ffffffff81395567] kmem_alloc hitcount: 6
caller: [ffffffff8125b844] alloc_fdmem hitcount: 6
caller: [ffffffff81415918] bio_alloc_bioset hitcount: 8
caller: [ffffffff813ecc44] security_context_to_sid_core hitcount: 17
caller: [ffffffff812621bb] seq_buf_alloc hitcount: 18
Totals:
Hits: 64
Entries: 12
Dropped: 0----------
Good! Just one more, I also want to see the offset of the symbols. :)
And this can dig deeper to investigate the size histogram, with filtering by caller.
----------
[root@localhost tracing]# echo \!hist:keys=caller.sym > events/probe/__kmalloc/trigger [root@localhost tracing]# echo hist:keys=size if caller==0xffffffff812621bb > events/probe/__kmalloc/trigger [root@localhost tracing]# cat events/probe/__kmalloc/hist
# trigger info: hist:keys=size:vals=hitcount:sort=hitcount:size=2048 if caller==0xffffffff812621bb [active]
size: 3024 hitcount: 1 size: 4096 hitcount: 12
Totals:
Hits: 13
Entries: 2
Dropped: 0[root@localhost tracing]#
---------
Yes! This interactivity is what I want :)
Another enhancement ideas what I want are here:
- Named hist instance, which can be shared among several events. Since probing an inlined function can make a several probe-events, those need to share a histogram among them.
- Multiple hist instances for each event, which allows us to compare several histograms which have different filters.
Anyway, without above, this look fine to me :)
Quoted 10 lines
The map code was also separated out into a separate file,
tracing_map.c, allowing it to be reused. It also adds a second tracer calledfunction_histthat actually does reuse the code, as an RFC patch.Patch 01/10 [tracing: Update cond flag when enabling or disabling..] is a fix for a problem noticed by Daniel and that fixes a problem in existing trigger code and should be applied regardless of whether the rest of the patchset is merged.
I've reviewed that.
Quoted 7 lines
As mentioned, patch 10/10 is an RFC patch implementing a new tracer based on the function tracer code. It's a fun little tool and is useful for a specific problem I'm working on (and is also a nice test of the
tracing_mapcode), but is an RFC because first, I'm not sure it would really be of general interest and secondly, it's POC-level quality and I'd need to spend more time fixing it up to make it upstreamable, but I don't want to waste my time if not.
BTW, I've hit a warning while testing:
[ 8431.319668] ------------[ cut here ]------------ [ 8431.319678] WARNING: CPU: 0 PID: 14413 at /home/mhiramat/ksrc/linux-3/kernel/trace/ftrace.c:5080 ftrace_init_array_ops+0x6e/0x90() [ 8431.319680] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 iptable_filter ip_tables tun bridge stp llc coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel glue_helper lrw gf128mul ablk_helper cryptd iTCO_wdt iTCO_vendor_support ipmi_si lpc_ich ipmi_msghandler mfd_core pcspkr i2c_i801 i2c_ismt shpchp acpi_cpufreq uinput sr_mod sd_mod cdrom ast syscopyarea sysfillrect sysimgblt drm_kms_helper ttm drm ahci igb libahci libata ptp pps_core dca i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod [ 8431.319736] CPU: 0 PID: 14413 Comm: ftracetest Not tainted 4.1.0-rc3+ #33 [ 8431.319738] Hardware name: Supermicro A1SAi/A1SAi, BIOS 1.0b 11/06/2013 [ 8431.319741] 0000000000000000 0000000037d828fa ffff880467eabc98 ffffffff817d5b48 [ 8431.319745] 0000000000000000 0000000000000000 ffff880467eabcd8 ffffffff810c70ba [ 8431.319748] ffff880467eabcb8 ffffffff820a2b80 ffffffff81197330 ffffffff820a2b80 [ 8431.319752] Call Trace: [ 8431.319760] [<ffffffff817d5b48>] dump_stack+0x45/0x57 [ 8431.319765] [<ffffffff810c70ba>] warn_slowpath_common+0x8a/0xc0 [ 8431.319769] [<ffffffff81197330>] ? function_hist_open+0x20/0x20 [ 8431.319772] [<ffffffff810c71ea>] warn_slowpath_null+0x1a/0x20 [ 8431.319776] [<ffffffff81183efe>] ftrace_init_array_ops+0x6e/0x90 [ 8431.319779] [<ffffffff811976d8>] function_hist_init+0x28/0x160 [ 8431.319783] [<ffffffff811918ee>] tracing_set_tracer+0x10e/0x1b0 [ 8431.319787] [<ffffffff8137cd8f>] ? xfs_file_buffered_aio_write+0xaf/0x240 [ 8431.319791] [<ffffffff81191bc0>] tracing_set_trace_write+0x90/0xd0 [ 8431.319796] [<ffffffff8123d2d7>] __vfs_write+0x37/0x110 [ 8431.319799] [<ffffffff81240198>] ? __sb_start_write+0x58/0x100 [ 8431.319804] [<ffffffff813d5393>] ? security_file_permission+0x23/0xa0 [ 8431.319808] [<ffffffff8123da09>] vfs_write+0xa9/0x1b0 [ 8431.319812] [<ffffffff810716fc>] ? do_audit_syscall_entry+0x6c/0x70 [ 8431.319816] [<ffffffff8123e8b5>] SyS_write+0x55/0xd0 [ 8431.319821] [<ffffffff817dd26e>] system_call_fastpath+0x12/0x71 [ 8431.319823] ---[ end trace 7f402f6ea6c9516c ]--- [ 8431.319826] ftrace ops had function_hist_call+0x0/0x150 for function
Here is the ftrace.c:5080
-----
void ftrace_init_array_ops(struct trace_array *tr, ftrace_func_t func)
{
/* If we filter on pids, update to use the pid function */
if (tr->flags & TRACE_ARRAY_FL_GLOBAL) {
if (WARN_ON(tr->ops->func != ftrace_stub)) <-- here
printk("ftrace ops had %pS for function\n",
tr->ops->func);
/* Only the top level instance does pid tracing */
if (!list_empty(&ftrace_pids)) {
set_ftrace_pid_function(func);
func = ftrace_pid_func;
}
}
tr->ops->func = func;
tr->ops->private = tr;
}-----
Since function_hist_call was introduced by 10/10, this warning was also occurred by it.
Thank you,
Signature · 5 lines
Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research & Development Group E-mail: [email protected]
Steven Rostedt
maintainerQuoted 3 lines · On Wed, 20 May 2015 16:19:47 -0500 Tom Zanussi <[email protected]>…
There are a couple of important bits of functionality that were present in v1 but not yet reimplemented in v5.
I take it that "yet" means they can still be implemented on top of v5 right? Without breaking backward compatibility of the interface?
Thanks for doing this, I'll try to get some time to look closer at the patches.
-- Steve
Quoted 11 lines · Steven Rostedt
Quoted 3 lines · On Wed, 20 May 2015 16:19:47 -0500 Tom Zanussi <[email protected]>…
There are a couple of important bits of functionality that were present in v1 but not yet reimplemented in v5.
I take it that "yet" means they can still be implemented on top of v5 right? Without breaking backward compatibility of the interface?
Yeah, that's referring to compound keys and sorting on multiple keys.
At this point, I'm so close to having that and have previous code to work from, so I'll just cook up a v6 without those caveats, and we don't have to worry about it. Give me a couple of days to get to that..
Tom
Quoted 4 lines
Thanks for doing this, I'll try to get some time to look closer at the patches.
-- Steve
Steven Rostedt
maintainerQuoted 6 lines · On Thu, 21 May 2015 09:29:15 -0500 Tom Zanussi <[email protected]>…
Yeah, that's referring to compound keys and sorting on multiple keys.
At this point, I'm so close to having that and have previous code to work from, so I'll just cook up a v6 without those caveats, and we don't have to worry about it. Give me a couple of days to get to that..
If theses patches are ready, and you can add those on top of this patch series, then just do that. I'll look into applying this when I get a chance.
If you plan on updating these patches, I'll hold off to v6 then.
-- Steve
Quoted 10 lines · Steven Rostedt
Quoted 6 lines · On Thu, 21 May 2015 09:29:15 -0500 Tom Zanussi <[email protected]>…
Yeah, that's referring to compound keys and sorting on multiple keys.
At this point, I'm so close to having that and have previous code to work from, so I'll just cook up a v6 without those caveats, and we don't have to worry about it. Give me a couple of days to get to that..
Quoted 6 lines
If theses patches are ready, and you can add those on top of this patch series, then just do that. I'll look into applying this when I get a chance.
If you plan on updating these patches, I'll hold off to v6 then.
I think I will be updating these patches, so better to hold off until v6 for now, thanks.
Tom
Quoted 1 line
-- Steve
Hi Masami,
Quoted 15 lines · Masami Hiramatsu
Hi Tom,
Quoted 11 lines · Tom Zanussi
This is v5 of the 'hist triggers' patchset, following feedback from v4.
Changes from v4:
This version addresses some problems and suggestions made by Daniel Wagner - a lot of the code was reworked to get rid of the distinction between keys and values, and as a result, both keys and values can be used as sort keys. As suggested, it also allows 'val=' to be absent in a trigger command - if no 'val' is specified, hitcount is assumed and automatically used as the only val.
Quoted 2 lines
Thank you for this amazing work! :)
Here is an example how I've used it.
Nice example - thanks for sharing it!
Quoted 29 lines
---------
[root@localhost perf]# ./perf probe -a '__kmalloccaller=$stack0 size' Added new event:
probe:__kmalloc (on__kmallocwith caller=$stack0 size)You can now use it in all perf tools, such as:
perf record -e probe:__kmalloc -aR sleep 1
[root@localhost perf]# cd
/sys/kernel/debug/tracing
[root@localhost tracing]# echo hist:keys=caller.sym > events/probe/__kmalloc/trigger [root@localhost tracing]# echo 1 > events/probe/__kmalloc/enable [root@localhost tracing]# cat events/probe/__kmalloc/hist# trigger info: hist:keys=caller.sym:vals=hitcount:sort=hitcount:size=2048 [active]caller: [
ffffffff811964d7]tracing_map_sort_entrieshitcount: 1
caller: [ffffffff81296120]load_elf_binaryhitcount: 1
caller: [ffffffff813eb98c]context_struct_to_stringhitcount: 1
caller: [ffffffff81264c8c]simple_xattr_allochitcount: 1
caller: [ffffffff811e0a02]shmem_initxattrshitcount: 1
caller: [ffffffff81295eb6]load_elf_phdrshitcount: 2
caller: [ffffffff8169c49b]sk_prot_allochitcount: 2
caller: [ffffffff81395567]kmem_allochitcount: 6
caller: [ffffffff8125b844]alloc_fdmemhitcount: 6
caller: [ffffffff81415918]bio_alloc_biosethitcount: 8
caller: [ffffffff813ecc44]security_context_to_sid_corehitcount: 17
caller: [ffffffff812621bb]seq_buf_allochitcount: 18
Quoted 7 lines
Totals:
Hits: 64 Entries: 12 Dropped: 0----------
Good! Just one more, I also want to see the offset of the symbols. :)
Sure, I could add a new 'sym-offset' modifier e.g. caller.sym-offset, or I can just have .sym always include the offset.
Quoted 14 lines
And this can dig deeper to investigate the size histogram, with filtering by caller.
----------
[root@localhost tracing]# echo \!hist:keys=caller.sym > events/probe/__kmalloc/trigger [root@localhost tracing]# echo hist:keys=size if caller==0xffffffff812621bb > events/probe/__kmalloc/trigger [root@localhost tracing]# cat events/probe/__kmalloc/hist# trigger info: hist:keys=size:vals=hitcount:sort=hitcount:size=2048 if caller==0xffffffff812621bb [active]size: 3024 hitcount: 1 size: 4096 hitcount: 12Totals:
Hits: 13 Entries: 2 Dropped: 0
Quoted 8 lines
[root@localhost tracing]#
---------
Yes! This interactivity is what I want :)Another enhancement ideas what I want are here:
- Named hist instance, which can be shared among several events. Since probing an inlined function can make a several probe-events, those need to share a histogram among them.
Makes sense - any ideas on how this would work from an interface perspective?
Would just allowing hist="myname": ... suffice? i.e. creating a hist trigger with hist="myname" would look for an existing trigger with that name - if found would use that, otherwise create a new instance with that name...
Quoted 3 lines
- Multiple hist instances for each event, which allows us to compare several histograms which have different filters.
Yeah, that would be a nice enhancement - will do that when I get a chance.
Quoted 1 line
Anyway, without above, this look fine to me :)
Great.
Quoted 6 lines
Quoted 6 lines
The map code was also separated out into a separate file,
tracing_map.c, allowing it to be reused. It also adds a second tracer calledfunction_histthat actually does reuse the code, as an RFC patch.
Quoted 7 lines
Quoted 4 lines
Patch 01/10 [tracing: Update cond flag when enabling or disabling..] is a fix for a problem noticed by Daniel and that fixes a problem in existing trigger code and should be applied regardless of whether the rest of the patchset is merged.
I've reviewed that.
Thanks for doing that.
Quoted 59 lines
Quoted 7 lines
As mentioned, patch 10/10 is an RFC patch implementing a new tracer based on the function tracer code. It's a fun little tool and is useful for a specific problem I'm working on (and is also a nice test of the
tracing_mapcode), but is an RFC because first, I'm not sure it would really be of general interest and secondly, it's POC-level quality and I'd need to spend more time fixing it up to make it upstreamable, but I don't want to waste my time if not.BTW, I've hit a warning while testing:
[ 8431.319668] ------------[ cut here ]------------ [ 8431.319678] WARNING: CPU: 0 PID: 14413 at /home/mhiramat/ksrc/linux-3/kernel/trace/ftrace.c:5080 ftrace_init_array_ops+0x6e/0x90() [ 8431.319680] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 iptable_filter ip_tables tun bridge stp llc coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel glue_helper lrw gf128mul ablk_helper cryptd iTCO_wdt iTCO_vendor_support ipmi_si lpc_ich ipmi_msghandler mfd_core pcspkr i2c_i801 i2c_ismt shpchp acpi_cpufreq uinput sr_mod sd_mod cdrom ast syscopyarea sysfillrect sysimgblt drm_kms_helper ttm drm ahci igb libahci libata ptp pps_core dca i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod [ 8431.319736] CPU: 0 PID: 14413 Comm: ftracetest Not tainted 4.1.0-rc3+ #33 [ 8431.319738] Hardware name: Supermicro A1SAi/A1SAi, BIOS 1.0b 11/06/2013 [ 8431.319741] 0000000000000000 0000000037d828fa ffff880467eabc98 ffffffff817d5b48 [ 8431.319745] 0000000000000000 0000000000000000 ffff880467eabcd8 ffffffff810c70ba [ 8431.319748] ffff880467eabcb8 ffffffff820a2b80 ffffffff81197330 ffffffff820a2b80 [ 8431.319752] Call Trace: [ 8431.319760] [<ffffffff817d5b48>] dump_stack+0x45/0x57 [ 8431.319765] [<ffffffff810c70ba>] warn_slowpath_common+0x8a/0xc0 [ 8431.319769] [<ffffffff81197330>] ? function_hist_open+0x20/0x20 [ 8431.319772] [<ffffffff810c71ea>] warn_slowpath_null+0x1a/0x20 [ 8431.319776] [<ffffffff81183efe>] ftrace_init_array_ops+0x6e/0x90 [ 8431.319779] [<ffffffff811976d8>] function_hist_init+0x28/0x160 [ 8431.319783] [<ffffffff811918ee>] tracing_set_tracer+0x10e/0x1b0 [ 8431.319787] [<ffffffff8137cd8f>] ? xfs_file_buffered_aio_write+0xaf/0x240 [ 8431.319791] [<ffffffff81191bc0>] tracing_set_trace_write+0x90/0xd0 [ 8431.319796] [<ffffffff8123d2d7>] __vfs_write+0x37/0x110 [ 8431.319799] [<ffffffff81240198>] ? __sb_start_write+0x58/0x100 [ 8431.319804] [<ffffffff813d5393>] ? security_file_permission+0x23/0xa0 [ 8431.319808] [<ffffffff8123da09>] vfs_write+0xa9/0x1b0 [ 8431.319812] [<ffffffff810716fc>] ? do_audit_syscall_entry+0x6c/0x70 [ 8431.319816] [<ffffffff8123e8b5>] SyS_write+0x55/0xd0 [ 8431.319821] [<ffffffff817dd26e>] system_call_fastpath+0x12/0x71 [ 8431.319823] ---[ end trace 7f402f6ea6c9516c ]--- [ 8431.319826] ftrace ops had function_hist_call+0x0/0x150 for functionHere is the ftrace.c:5080
-----
voidftrace_init_array_ops(struct trace_array *tr, ftrace_func_t func){ /* If we filter on pids, update to use the pid function */ if (tr->flags & TRACE_ARRAY_FL_GLOBAL) { if (WARN_ON(tr->ops->func != ftrace_stub)) <-- here printk("ftrace ops had %pS for function\n", tr->ops->func); /* Only the top level instance does pid tracing */ if (!list_empty(&ftrace_pids)) { set_ftrace_pid_function(func); func = ftrace_pid_func; } } tr->ops->func = func; tr->ops->private = tr; }
Quoted 5 lines
-----
Since
function_hist_callwas introduced by 10/10, this warning was also occurred by it.
Right, why it's an RFC ;-) I need to look some more at the ftrace code and figure out how to hook it up properly...
Thanks,
Tom
Quoted 4 lines
Thank you,
Quoted 60 lines · Tom Zanussi
Hi Masami,
Quoted 15 lines · Masami Hiramatsu
Hi Tom,
Quoted 11 lines · Tom Zanussi
This is v5 of the 'hist triggers' patchset, following feedback from v4.
Changes from v4:
This version addresses some problems and suggestions made by Daniel Wagner - a lot of the code was reworked to get rid of the distinction between keys and values, and as a result, both keys and values can be used as sort keys. As suggested, it also allows 'val=' to be absent in a trigger command - if no 'val' is specified, hitcount is assumed and automatically used as the only val.
Quoted 2 lines
Thank you for this amazing work! :)
Here is an example how I've used it.Nice example - thanks for sharing it!
Quoted 29 lines
---------
[root@localhost perf]# ./perf probe -a '__kmalloccaller=$stack0 size' Added new event:
probe:__kmalloc (on__kmallocwith caller=$stack0 size)You can now use it in all perf tools, such as:
perf record -e probe:__kmalloc -aR sleep 1
[root@localhost perf]# cd
/sys/kernel/debug/tracing
[root@localhost tracing]# echo hist:keys=caller.sym > events/probe/__kmalloc/trigger [root@localhost tracing]# echo 1 > events/probe/__kmalloc/enable [root@localhost tracing]# cat events/probe/__kmalloc/hist# trigger info: hist:keys=caller.sym:vals=hitcount:sort=hitcount:size=2048 [active]caller: [
ffffffff811964d7]tracing_map_sort_entrieshitcount: 1
caller: [ffffffff81296120]load_elf_binaryhitcount: 1
caller: [ffffffff813eb98c]context_struct_to_stringhitcount: 1
caller: [ffffffff81264c8c]simple_xattr_allochitcount: 1
caller: [ffffffff811e0a02]shmem_initxattrshitcount: 1
caller: [ffffffff81295eb6]load_elf_phdrshitcount: 2
caller: [ffffffff8169c49b]sk_prot_allochitcount: 2
caller: [ffffffff81395567]kmem_allochitcount: 6
caller: [ffffffff8125b844]alloc_fdmemhitcount: 6
caller: [ffffffff81415918]bio_alloc_biosethitcount: 8
caller: [ffffffff813ecc44]security_context_to_sid_corehitcount: 17
caller: [ffffffff812621bb]seq_buf_allochitcount: 18Quoted 7 lines
Totals:
Hits: 64 Entries: 12 Dropped: 0----------
Good! Just one more, I also want to see the offset of the symbols. :)
Quoted 2 lines
Sure, I could add a new 'sym-offset' modifier e.g. caller.sym-offset, or I can just have .sym always include the offset.
Hmm, can we reuse ftrace's options? We already have options/sym-offset and options/sym-addr under debugfs/tracing/. E.g.
# options/sym-offset=0 options/sym-addr=0
caller: seq_buf_alloc
# options/sym-offset=0 options/sym-addr=1
caller: [ffffffff812621bb] seq_buf_alloc
# options/sym-offset=1 options/sym-addr=0
caller: seq_buf_alloc+0x1b
# options/sym-offset=1 options/sym-addr=1
caller: [ffffffff812621bb] seq_buf_alloc+0x1b
Quoted 24 lines
Quoted 15 lines
And this can dig deeper to investigate the size histogram, with filtering by caller.
----------
[root@localhost tracing]# echo \!hist:keys=caller.sym > events/probe/__kmalloc/trigger [root@localhost tracing]# echo hist:keys=size if caller==0xffffffff812621bb > events/probe/__kmalloc/trigger [root@localhost tracing]# cat events/probe/__kmalloc/hist# trigger info: hist:keys=size:vals=hitcount:sort=hitcount:size=2048 if caller==0xffffffff812621bb [active]size: 3024 hitcount: 1 size: 4096 hitcount: 12Totals:
Hits: 13 Entries: 2 Dropped: 0Quoted 8 lines
[root@localhost tracing]#
---------
Yes! This interactivity is what I want :)Another enhancement ideas what I want are here:
- Named hist instance, which can be shared among several events. Since probing an inlined function can make a several probe-events, those need to share a histogram among them.
Quoted 7 lines
Makes sense - any ideas on how this would work from an interface perspective?
Would just allowing hist="myname": ... suffice? i.e. creating a hist trigger with hist="myname" would look for an existing trigger with that name - if found would use that, otherwise create a new instance with that name...
Yeah, that looks good to me :)
Quoted 88 lines
Quoted 3 lines
- Multiple hist instances for each event, which allows us to compare several histograms which have different filters.
Yeah, that would be a nice enhancement - will do that when I get a chance.
Quoted 1 line
Anyway, without above, this look fine to me :)
Great.
Quoted 6 lines
Quoted 6 lines
The map code was also separated out into a separate file,
tracing_map.c, allowing it to be reused. It also adds a second tracer calledfunction_histthat actually does reuse the code, as an RFC patch.Quoted 7 lines
Quoted 4 lines
Patch 01/10 [tracing: Update cond flag when enabling or disabling..] is a fix for a problem noticed by Daniel and that fixes a problem in existing trigger code and should be applied regardless of whether the rest of the patchset is merged.
I've reviewed that.
Thanks for doing that.
Quoted 61 lines
Quoted 7 lines
As mentioned, patch 10/10 is an RFC patch implementing a new tracer based on the function tracer code. It's a fun little tool and is useful for a specific problem I'm working on (and is also a nice test of the
tracing_mapcode), but is an RFC because first, I'm not sure it would really be of general interest and secondly, it's POC-level quality and I'd need to spend more time fixing it up to make it upstreamable, but I don't want to waste my time if not.BTW, I've hit a warning while testing:
[ 8431.319668] ------------[ cut here ]------------ [ 8431.319678] WARNING: CPU: 0 PID: 14413 at /home/mhiramat/ksrc/linux-3/kernel/trace/ftrace.c:5080 ftrace_init_array_ops+0x6e/0x90() [ 8431.319680] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 iptable_filter ip_tables tun bridge stp llc coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel glue_helper lrw gf128mul ablk_helper cryptd iTCO_wdt iTCO_vendor_support ipmi_si lpc_ich ipmi_msghandler mfd_core pcspkr i2c_i801 i2c_ismt shpchp acpi_cpufreq uinput sr_mod sd_mod cdrom ast syscopyarea sysfillrect sysimgblt drm_kms_helper ttm drm ahci igb libahci libata ptp pps_core dca i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod [ 8431.319736] CPU: 0 PID: 14413 Comm: ftracetest Not tainted 4.1.0-rc3+ #33 [ 8431.319738] Hardware name: Supermicro A1SAi/A1SAi, BIOS 1.0b 11/06/2013 [ 8431.319741] 0000000000000000 0000000037d828fa ffff880467eabc98 ffffffff817d5b48 [ 8431.319745] 0000000000000000 0000000000000000 ffff880467eabcd8 ffffffff810c70ba [ 8431.319748] ffff880467eabcb8 ffffffff820a2b80 ffffffff81197330 ffffffff820a2b80 [ 8431.319752] Call Trace: [ 8431.319760] [<ffffffff817d5b48>] dump_stack+0x45/0x57 [ 8431.319765] [<ffffffff810c70ba>] warn_slowpath_common+0x8a/0xc0 [ 8431.319769] [<ffffffff81197330>] ? function_hist_open+0x20/0x20 [ 8431.319772] [<ffffffff810c71ea>] warn_slowpath_null+0x1a/0x20 [ 8431.319776] [<ffffffff81183efe>] ftrace_init_array_ops+0x6e/0x90 [ 8431.319779] [<ffffffff811976d8>] function_hist_init+0x28/0x160 [ 8431.319783] [<ffffffff811918ee>] tracing_set_tracer+0x10e/0x1b0 [ 8431.319787] [<ffffffff8137cd8f>] ? xfs_file_buffered_aio_write+0xaf/0x240 [ 8431.319791] [<ffffffff81191bc0>] tracing_set_trace_write+0x90/0xd0 [ 8431.319796] [<ffffffff8123d2d7>] __vfs_write+0x37/0x110 [ 8431.319799] [<ffffffff81240198>] ? __sb_start_write+0x58/0x100 [ 8431.319804] [<ffffffff813d5393>] ? security_file_permission+0x23/0xa0 [ 8431.319808] [<ffffffff8123da09>] vfs_write+0xa9/0x1b0 [ 8431.319812] [<ffffffff810716fc>] ? do_audit_syscall_entry+0x6c/0x70 [ 8431.319816] [<ffffffff8123e8b5>] SyS_write+0x55/0xd0 [ 8431.319821] [<ffffffff817dd26e>] system_call_fastpath+0x12/0x71 [ 8431.319823] ---[ end trace 7f402f6ea6c9516c ]--- [ 8431.319826] ftrace ops had function_hist_call+0x0/0x150 for functionHere is the ftrace.c:5080
-----
voidftrace_init_array_ops(struct trace_array *tr, ftrace_func_t func){ /* If we filter on pids, update to use the pid function */ if (tr->flags & TRACE_ARRAY_FL_GLOBAL) { if (WARN_ON(tr->ops->func != ftrace_stub)) <-- here printk("ftrace ops had %pS for function\n", tr->ops->func); /* Only the top level instance does pid tracing */ if (!list_empty(&ftrace_pids)) { set_ftrace_pid_function(func); func = ftrace_pid_func; } } tr->ops->func = func; tr->ops->private = tr; }-----
Quoted 6 lines
Quoted 3 lines
Since
function_hist_callwas introduced by 10/10, this warning was also occurred by it.Right, why it's an RFC ;-) I need to look some more at the ftrace code and figure out how to hook it up properly...
Thank you!
Signature · 5 lines
Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research & Development Group E-mail: [email protected]