[lkml]   [2015]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 07/10] tracing: Add 'hist' event trigger command
On 2015/06/09 6:32, Tom Zanussi wrote:
> '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.
> Signed-off-by: Tom Zanussi <>
> fixes sort key parsing
> Signed-off-by: Tom Zanussi <>
> Add sym-offset
> And change sym, add more space for both. And make modifiers stricter.
> Signed-off-by: Tom Zanussi <>

Why does this have same singned-off-bys? :)

BTW, this looks a bit big to review and including many different features.
It seems to be broken into several incremental patches, like

- Add a basic hist trigger (key, val, size and simple hitcount sorting)
- Add multiple keys and values support
- Add "sort" attribute
- Add "continue" and "pause" attribute
- Add "clear" attribute
- Support ".hex" option for keys and vals
- Support ".sym" and ".sym-offset" options for keys and vals
- Support ".execname" option for keys
- Support ".syscall" option for keys
- Support ".stacktrace" option for keys

Thank you,

Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group

 \ /
  Last update: 2015-06-10 17:01    [W:0.170 / U:1.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site