Messages in this thread |  | | | From | KOSAKI Motohiro <> | | Subject | Re: [PATCH] new irq tracer | | Date | Fri, 27 Feb 2009 12:33:34 +0900 (JST) |
| |
> > the lttng tracepoints wrap the calls to _handle_IRQ_event in 3 > > different places. So the above suggested irq tracepoint provides the > > same information with 4 less tracepoints in the code. So I believe its > > simpler - plus we can understand which action handlers are handling the > > interrupt. > > > > The main thing I dislike about only tracing action->handler() calls is > that you are not tracing an IRQ per se, but rather the invocation of a > given handler within the interrupt. For instance, it would be difficult > to calculate the maximum interrupt latency for a given interrupt line, > because you don't have the "real" irq entry/exit events, just the > individual handler() calls.
I agree with IRQ latency tracing is very important. So now, We understand we have another two good requirement.
Therefore, I can agree to Mathieu's separete trace point idea and Jason's current patch.
Thanks! good discussion.
> > But I agree that knowing which handler is called is important. > > How about this compromise : > > trace_irq_entry(irq, action) > _handle_IRQ_event() > for each action { > trace_irq_handler(action, ret); > ret = action->handler(irq, action->dev_id); > ... > } > trace_irq_exit(action_ret); > > Would that give you the information you need ? > > Here trace_irq_handler would be passed the _current_ action invoked and > the _previous_ action return value. Note that we should initialize > irqreturn_t ret to some initial value if we do this. That should keep > the tracing overhead minimal.
|  |