Messages in this thread |  | | Date | Wed, 10 Jun 2015 23:14:40 +0900 | From | Masami Hiramatsu <> | Subject | Re: [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 <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
|  |