Message-ID: <20081124112842.GA15615@Krystal>
Date:	Mon, 24 Nov 2008 06:28:42 -0500
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	ltt-dev@...ts.casi.polymtl.ca
Cc:	Zhaolei <zhaolei@...fujitsu.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org
Subject: LTTng kernel integration roadmap, update

(sorry for repost, I messed up lkml address in the original post, please
reply to this one)

Hi everyone,

Let's see what the current status is and what we still have to focus on
before submission. First I'd like to say a big thanks to Zhaolei from
Fujitsu who did a great job for the debugfs-based LTTng control we now
have.

- trace_clock()
  - Port to the -tip tree. Submit. Should be ready for inclusion after
    the few rounds of review on LKML it had.
  Assigned-to: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>

- LTTng instrumentation
  - Port to the -tip tree, submit incrementally.
  Assigned-to: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>

- Add periodical subbuffer flush for streaming
  - Will be required by ascii text output.
  - Also requires modification to lttd so it can only transmit the
    buffer data, without the padding. Some modification to LTTV might be
    needed to cope with variable-sized subbuffers (we would need an
    index to be able to seek with O(log(num subbuffers)) as we currently
    do, or we would have to use sparse files for trace files).
  Assigned-to: François Prenoveau <francois.prenoveau@...ymtl.ca>

- Marker ID management
  Background :
  The markers are currently used to identify the numerical event IDs
  associated with a named event as well as the event types (format
  string) associated with that event. Those two informations are kept in
  a table written in the metadata channel. A "channel" could be thought
  as being a set of per-cpu buffers, where information transits. This
  information would typically be related to a specific tracer. Note,
  however, that the information generated by a tracer should always be
  parseable generically and be transformable into text output by a
  simple parser, because we want to permit analysis across information
  logged by the various tracer.

  Action item :
  The current event IDs are global to the whole kernel. It would be
  beneficial to change their scope so they are per-channel instead,
  because we can then encode most events in the low-order bits of the
  event ID bits, therefore keeping events as small as possible.

- Channel management
  Background :
  LTTng currently has the following statically declared channels :

  cpu (default channel)
  metadata (marker name, marker ID, marker format string table)
  interrupts (interrupt handlers table, interrupt handler connexion
  events)
  modules (loaded module table, module load/free events)
  network (active interfaces table, interface up/down events)
  processes (processes existing at trace start table, scheduling events)

  Action item :
  But if we want to integrate ftrace easily within this framework, we
  would like to offer an API so tracers can dynamically register a new
  channel whenever they are loaded.

  Note that the marker ID management and channel management are closely
  tied together; IDs would be per-channel, and channels would be
  registered by tracers.

- trimmed-down lttv for the kernel tree
  Need to look at
  git://git.kernel.org/pub/scm/linux/kernel/git/sam/test.git#master
  tests/ directory, which permits building userspace tools with the
  Linux kernel. I recently got the idea of populating debugfs with
  userspace tools that would sits in kernel module data. How (in)sane
  does this idea look ? That would seems like a rather good solution to
  ship the userspace tool with the kernel.

- Port ftrace to LTTng
  ftrace could ask LTTng to create channels for its data, and would use
  this handle to record into the buffers. Given that LTTng allows
  multiple traces to be taken at once, and given LTTng exports all its
  trace control primitives as in-kernel API, ftrace could use those to
  automatically control tracing behavior from within the kernel wrt the
  buffers for which it produces _and_ consumes information.

  I think we might need to add the notion of traces for which buffers
  are meant to be consumed within the kernel (private) and not exported
  to userspace. Or maybe the current reference counting which insure
  that at most one reader is connected on a trace buffer, is enough.

- ASCII text output.
  - Merge sort done within the kernel. Binary-to-text translation also
    done within the kernel.
  Assigned-to: Zhaolei <zhaolei@...fujitsu.com>
  Assigned-to: Lai Jiangshan <laijs@...fujitsu.com>

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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