[ltt-dev] lttng development plan

Mathieu Desnoyers compudj at krystal.dyndns.org
Mon Jan 19 20:55:53 EST 2009


* Lai Jiangshan (laijs at cn.fujitsu.com) wrote:
> Mathieu Desnoyers wrote:
> > Hi Gui,
> > 
> > My short-term roadmap is (those are the show stoppers) :
> > 
> > - Get lttng ascii dump to work.
> >   - create periodical buffer flush per-cpu timer for data streaming
> >   - Modify LTTng/lttd/lttv to support variable-sized buffers, so we
> >     don't have to copy the padding. This implies creating an index in
> >     lttv when opening the trace to know where the subbuffer start is.
> >   - Waiting for Lai's channel and event ID management modifications
> >     following my comments. This is needed so the IDs stays valid for the
> >     binary->ascii in-kernel converter.
> > - Support dynamic frequency scaling on x86.
> > 
> > Other nice-to-have, but not a priority :
> > 
> >   - Add support for Performance Monitoring Counters (PMC) so they can be
> >     dumped in the traces.
> >   - Put back support for kernel and userspace stack dump so it can be
> >     connected to any given tracepoint.
> >   - Linux ABI for fast userspace tracing.
> >     - Then, add NPTL instrumentation (mutexes, phtreads).
> >   - Integrate LTTng with LKCD, test with kernel crash extraction,
> >     create tools to simplify extraction of traces from crashed kernel,
> >     integrate those tools to ltt-control.
> 
> We will implement it.
> 

Great :) Note that there has already been some work done on this. This
in available as an addition to the crosscrash tool :

http://sourceforge.net/projects/crosscrash/

There is a cross-crash-ltt.patch file available on the project website,
but I think it has not been updated since 2007. Some integration work
will have to be done.

Also outputting the traces in the video card's memory would be a
nice-to-have, because this memory often survives hot reboots.

> >   - Create an in-kernel event filtering module which connects on
> >     LTTng.
> >   - Early boot tracing.
> 
> What your plan for early boot tracing?
> 

Basically :

- Finding where is the soonest in main.c we can put tracepoints and
  start tracing (this is probably after rcu and memory init).
- Figuring out the TSC problems that could arise with tracing a booting
  system.
- Allowing kernel command line arguments in a special LTTng module to
  control early boot tracing.
- Allowing the kernel to allocate buffers very early at boot time. This
  would also make sure that we have large contiguous memory regions
  available for allocation.

Please don't hesitate to ask if you need more details.

Best regards,

Mathieu

> >   - Virtual machine tracing support (time synchronisation).
> >   - Cluster and distributed computer tracing support (time
> >     synchronisation).
> >   - Port kmemtrace, ftrace, blktrace, kvmtrace and others to LTTng.
> >     Each could have its own channel.
> > 
> > Please ask if you need more information on specific items.
> > 
> > Best regards, and many thanks to Fujitsu for the good work,
> > 
> > Mathieu
> > 
> > 
> > * Gui Jianfeng (guijianfeng at cn.fujitsu.com) wrote:
> >> Hi Mathieu,
> >>
> >> I'd like to know whether you have a plan or roadmap 
> >> for lttng's further developping.
> >> If you have one, would you share it?
> >>
> >> -- 
> >> Regards
> >> Gui Jianfeng
> >>
> > 
> 
> 
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68




More information about the lttng-dev mailing list