[ltt-dev] lttng development plan
laijs at cn.fujitsu.com
Tue Jan 20 01:58:36 EST 2009
Mathieu Desnoyers wrote:
> * 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 :
> 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.
I will use kdump. kdump is in the mainline, I think kdump is better
than crosscrash & LKCD.
>>> - Create an in-kernel event filtering module which connects on
>>> - 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
> - 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,
>>> - Virtual machine tracing support (time synchronisation).
>>> - Cluster and distributed computer tracing support (time
>>> - 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,
>>> * 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?
>>>> Gui Jianfeng
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
More information about the lttng-dev