Re: [PATCH v7 07/10] tracing: Add 'hist' event trigger command

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

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 <tom.zanussi@linux.intel.com>
> 
> fixes sort key parsing
> 
> Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
> 
> Add sym-offset
> 
> And change sym, add more space for both.  And make modifiers stricter.
> 
> Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>


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,



-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@hitachi.com