Message-ID: <1433953939.25953.12.camel@picadillo>
Subject: Re: [PATCH v7 07/10] tracing: Add 'hist' event trigger command
From: Tom Zanussi <tom.zanussi@linux.intel.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: rostedt@goodmis.org, daniel.wagner@bmw-carit.de, namhyung@kernel.org,
        josh@joshtriplett.org, andi@firstfloor.org,
        linux-kernel@vger.kernel.org
Date: Wed, 10 Jun 2015 11:32:19 -0500
In-Reply-To: <55784650.6050907@hitachi.com>
References: <cover.1433797842.git.tom.zanussi@linux.intel.com>
	 <b4e262ff18d468da950b21c099f75a6b1fa82a48.1433797842.git.tom.zanussi@linux.intel.com>
	 <55784650.6050907@hitachi.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4142
Lines: 108

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/