From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Subject: [ltt-dev] lttng development plan
Date: Thu, 22 Jan 2009 23:49:40 -0500 [thread overview]
Message-ID: <20090123044940.GB24971@Krystal> (raw)
In-Reply-To: <20090123213907.34DC.KOSAKI.MOTOHIRO@jp.fujitsu.com>
* KOSAKI Motohiro (kosaki.motohiro at jp.fujitsu.com) wrote:
> > > > - 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.
>
> Just dumb question.
>
> Do you receive this feature requesting from anybody?
>
> Currently, expected flight-recored mode user is enterprise guys.
> They usually use crash dumps. then, kernel panic cause tons i/o anyway
> although tracing infomation don't.
>
> Then, this feature doesn't reduce rebooting times, I think.
>
Yes, people in enterprise need to be able to diagnose _why_ the system
failed. Failing once is acceptable from a customer perspective, but
failing again isn't. In this case, being able to extract the last events
before the crash can be very valuable and helps solving the problems
before they happen again.
I agree with you that short reboot times are also very important in
production, and we need to find a solution which ideally could provide
both :
- short reboot time
- availability of tracing data across reboot
I think that using memory such as what is available in video cards
(which survives hot reboots) could be a solution to this : the system
could reboot as soon as it crashes, and the trace would be available to
be extracted from the machine once the system is back online (given that
we put the next trace buffers at different memory addresses of the video
card).
Long reboot times seems to be a core problem with the crash dump
approach. Do you think the video card memory scheme could become
attractive enough that people would need it ?
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2009-01-23 4:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49646F42.5040003@cn.fujitsu.com>
2009-01-07 17:05 ` Mathieu Desnoyers
2009-01-19 3:43 ` Lai Jiangshan
2009-01-20 1:55 ` Mathieu Desnoyers
2009-01-20 6:58 ` Lai Jiangshan
2009-01-23 3:21 ` KOSAKI Motohiro
2009-01-23 3:21 ` KOSAKI Motohiro
2009-01-23 4:49 ` Mathieu Desnoyers [this message]
2009-02-02 4:59 ` Gui Jianfeng
2009-02-03 5:11 ` Mathieu Desnoyers
2009-02-11 6:33 ` Zhaolei
2009-02-11 6:50 ` Mathieu Desnoyers
2009-02-11 7:24 ` Zhaolei
2009-02-11 7:37 ` Mathieu Desnoyers
2009-02-19 8:17 ` Zhaolei
2009-03-02 7:01 ` Zhaolei
2009-03-03 19:25 ` Mathieu Desnoyers
2009-03-29 8:41 ` [ltt-dev] [PATCH 0/3] In-kernel filter module Zhaolei
2009-03-29 8:42 ` [ltt-dev] [PATCH 1/3] Remove old per-type filter Zhaolei
2009-03-29 8:43 ` [ltt-dev] [PATCH 2/3] Change ltt_run_filter_functor arguments to support in-kernel filter Zhaolei
2009-03-29 8:44 ` [ltt-dev] [PATCH 3/3] In-kernel filter module Zhaolei
2009-04-06 17:52 ` Mathieu Desnoyers
2009-04-07 5:45 ` Zhaolei
2009-04-07 16:48 ` Mathieu Desnoyers
2009-04-08 3:19 ` Zhaolei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090123044940.GB24971@Krystal \
--to=compudj@krystal.dyndns.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox