[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55784650.6050907@hitachi.com>
Date: Wed, 10 Jun 2015 23:14:40 +0900
From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To: Tom Zanussi <tom.zanussi@...ux.intel.com>, rostedt@...dmis.org
CC: daniel.wagner@...-carit.de, namhyung@...nel.org,
josh@...htriplett.org, andi@...stfloor.org,
linux-kernel@...r.kernel.org
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@...ux.intel.com>
>
> fixes sort key parsing
>
> Signed-off-by: Tom Zanussi <tom.zanussi@...ux.intel.com>
>
> Add sym-offset
>
> And change sym, add more space for both. And make modifiers stricter.
>
> Signed-off-by: Tom Zanussi <tom.zanussi@...ux.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@...achi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists