Messages in this thread |  | | Subject | Re: [PATCH v7 07/10] tracing: Add 'hist' event trigger command | From | Tom Zanussi <> | Date | Wed, 10 Jun 2015 11:32:19 -0500 |
| |
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, > > >
|  |