Messages in this thread | | | Date | Wed, 25 Feb 2009 11:58:49 -0500 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH] new irq tracer |
| |
* Masami Hiramatsu (mhiramat@redhat.com) wrote: > > > KOSAKI Motohiro wrote: > >> /** > >> * handle_IRQ_event - irq action chain handler > >> * @irq: the interrupt number > >> @@ -354,7 +358,9 @@ irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action) > >> local_irq_enable_in_hardirq(); > >> > >> do { > >> + trace_irq_entry(irq); > >> ret = action->handler(irq, action->dev_id); > >> + trace_irq_exit(irq, ret); > >> if (ret == IRQ_HANDLED) > >> status |= action->flags; > >> retval |= ret; > > > > Nobdy want unnecessary redundant tracepoint. > > Please discuss with mathieu, and merge his tracepoint. > > Hmm, from the viewpoint of trouble shooting, the place of LTTng's tracepoint > is enough. However, from the same viewpoint, it should pass irq-number > to irq-exit event too, because we may lost some previous events by buffer-overflow > etc. > > trace_irq_entry(irq, NULL); > ret = _handle_IRQ_event(irq, action); > trace_irq_exit(irq, ret); > ^^^^ >
I seriously doubt we should consider a trace with missing events as "reliable". If your only argument is that when the buffers are not large enough we could lose events, then I think we should just hint people at doing the right thing, which is to tweak the tracer parameters (e.g. larger buffers) so they stop losing events.
A trace with events lost is really a scenario close to a corrupted trace because we don't know which event has been lost, nor where. I don't think we should increase the event size to support that kind of broken scenario.
Mathieu
> Thank you, > > -- > Masami Hiramatsu > > Software Engineer > Hitachi Computer Products (America) Inc. > Software Solutions Division > > e-mail: mhiramat@redhat.com >
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |