Re: [ANNOUNCE] New utility: 'trace'

* Ted Ts'o <tytso@mit.edu> wrote:

> On Tue, Nov 16, 2010 at 10:04:40PM +0100, Thomas Gleixner wrote:
> > If you've booted the new kernel you can run 'trace check' to double
> > check that all events used by the tool are available:
> > 
> >  $ trace check
> > 
> >  Checking whether the kernel has all required events ...
> >   ... Checking event  raw_syscalls:sys_enter:r      : ok
> >   ...
> >   ... Checking event  sched:sched_stat_runtime:r    : ok
> >  Good: all required event types are supported by this kernel.
> >  The 'trace' utility will be fully functional.
> 
> For the benefit of people who create tracepoints, what restrictions
> does trace have with respect to event types, and is this anticipated
> to change in the future?

There are no conceptual restrictions - this v1 version of the tool uses a (small) 
subset of tracepoints right now.

ext4 tracepoints will be used once someone writes a trace code (or plugin) for it - 
i think beyond simply displaying that trace data it would also be useful to 
interpret it to a certain degree? They could also interact with the block events: so 
we could track which inode (or other ext4 data structure) generates what IO, what 
the latencies are and which task originated things. We could track what the wait 
reasons are.

At that point (when ext4 event support is added) we'd add 'trace check' test as 
well, and would generally try to make sure that if distros enable events that all 
commonly used tracepoints are available as well.

I.e. the long term goal would be to create a widely available tool, which, amongst 
other things, can be used to record and report ext4 events as well - with no kernel 
reboots or tool rebuilds required.

> > The combo diffstat of the tool is appended at the end of the mail. The
> > overwhelming majority of changes is on the tooling side - it uses
> > existing perf events facilities and features to implement the tool.
> 
> What about the filtering and other general features/functionality of
> ftrace?  Is the anticipation that this will be ported over to perf?
> What about things like blktrace?

Yeah, i'd love to see all that available. Filtering is available already on the 
kernel perf event side and could be added as an option.

> Not that I expect all of this will be working with this initial
> release, but I'm curious about the long-term roadmap of this
> interface.  (Obviously subject to change as we learn more, etc.  But
> I'd love to hear what your current thoughts and plans are.)
>
> P.S.  What about sysrq-z?  Is that going to stay with ftrace side of
> the tracing architecture?

What we are working towards is to unify the whole tracing infrastructure. IMHO it's 
not really acceptable that there is an 'ftrace side' and a 'perf side', with feature 
overlap and feature mismatch and general confusion.

Thanks,

	Ingo