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

[KOSAKI Motohiro]

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.

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


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.

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.


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