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

[Tom Zanussi <tom.zanussi@linux.intel.com>]

On Wed, 2015-06-10 at 23:14 +0900, Masami Hiramatsu wrote:
> 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? :)
> 

Hmm, yeah, forgot to squash the comments when I squashed the commits,
thanks for noticing.

> 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
> 

Yeah, it just kept growing and growing with each revision...

Now that it's pretty much feature-complete, I'll break the features out
again in a new revision, for easier review.

Thanks,

Tom


> 
> Thank you,
> 
> 
>