[ltt-dev] lttng development plan

[laijs@cn.fujitsu.com (Lai Jiangshan)]

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 :
> 
> 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.

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