[ltt-dev] [PATCH v2] add tracepoints of panic and kexec

[Mathieu Desnoyers]

* KOSAKI Motohiro (kosaki.motohiro at jp.fujitsu.com) wrote:
> Hi Mathieu,
> 
> > > We need to know the time and other information that panic happened.
> > > And output message is integrated in lttng with other messages.
> > > I don't think it's bad idea which we use for a long time.
> > > 
> > > And this is a *key message*, event should be generated efficient/elegant.
> > > 
> > > Sorry for participated in this discuss with bad manners.
> > > 
> > 
> > No no, that's ok :) Well, if the panic event is useful, I have nothing
> > against it. I just think that if the tracer starts hooking in some parts
> > of the kernel to do something else than just logging events (e.g.
> > triggering a full dump), then we should think about using the standard
> > notifiers interface (mabe in addition to tracepoints).
> > 
> > And about the "I won't create the patches myself", it's just a matter of
> > priority. I focus on mainline integration currently, but I have nothing
> > against integrating work done by others in the LTTng project. I hope
> > this clarifies my point of view a bit.
> > 
> > Mathieu
> 
> I read this thread and feel interesting.
> Thank you mathiu, good explaination.
> 
> I agree to Fujitsu have the responsibility to make panic prove consumer.
> (eg. integrate lttng directly or generic notifier mechanism)
> 
> ok, we receive this responcibility ball.
> 
> 
> and, I'd like to talk about fujitsu tracer development team goal.
> We also strongly want to merge lttng to upstream. we agree it's top
> priority.
> and our next priority, we need good flight recorder supporting.
>   - low overhead
>   - transparent to end-user
>     (vendor want to turn on, by default)
>   - easy analysis to the support engineer of vendor (include fujitsu).
>   et al.
> 
> in flight recorder usage, we need to ignore the event of happend
> after panic() function.
> I believe it's general requirement of flight recorder, not fujitsu 
> specific requirement.
> 

I see. This is where you need to have an event saying "the kernel
stopped here". I'd prefer to leave tracing "on" at that point, just in
case something interesting happens within the panic() handler or after
it has run. Therefore having a "panic" tracepoint makes sense.

> and ok, we integrate this patch to lttng after upstream merge.
> 

I'm ok to integrate it now into the LTTng tree. I'll push the patches
upstream piece-by-piece anyway (mostly for instrumentation). The thing I
would like, in addition to a panic tracepoint, would be to add a panic()
notifier in the linux kernel. This notifier chain could call into LTTng
so we could do whatever action we have to do on the trace buffers (e.g.
to send them remotely over the network). Do you think this would be
useful ? Or maybe is there already something avalailable more widely
that we could hook into am I not fully aware of ?

> 
> last week, gui-san did hear your development plan.
> I and gui-san is making the plan of fujitsu short term and long term
> development now.
> So, periodically development plain dumping and/or it's your priority
> explanation are very helpful for us, it help to adjust our human resource.
> 

That's great. I really like the way things are moving forward. It's a
pleasure to work with you guys !

> Thanks!
> 
> 
> 
> btw, your "[Regression] High latency when doing large I/O" thread is
> very interesting and good explain why lttng is useful for lkml guys.
> I plan to demonstrate similar thing on MM area. that's my homework.
> 

Yes, I happen to learn some I/O scheduler basics at the same time. These
are some very interesting problems to tackle, and I hope it will
demonstrate the tracer usefulness to the community. Please CC me on such
MM problems, it's always a lot of fun. :)

> 
>   - kosaki "double as fujitsu tracing tech-lead/manager as well as MM developer"
> 

Mathieu, LTTng lead trying to write a Ph.D. thesis :)


> 

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