Messages in this thread | | | Date | Wed, 25 Mar 2009 14:30:24 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [patch 2/9] LTTng instrumentation - irq |
| |
* Ingo Molnar (mingo@elte.hu) wrote: > > * Ingo Molnar <mingo@elte.hu> wrote: > > > > > * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote: > > > > > If we want to do this logically, without thinking about tracer > > > performance impact, we could/should do : > > > > > > trace_irq_entry(irqno, pt_regs) > > > for_each_handler() { > > > trace_irq_handler_entry(action) > > > action->handler() > > > trace_irq_handler_exit(ret) > > > } > > > trace_irq_exit(retval) > > > > Not really. > > Put differently: we seem to agree on handler invocation entry/exit > events (and those are handled by Jason's patch already), and that's > good. >
Yes, we need to get this information into the trace stream somehow.
> I dont think we need two events for physical IRQ events though. One > is enough: entry event. What meaning does 'retval' have in your > pseudo-code above? None typically. >
Hrm, an event means more that the "payload" it has. Just saving "here is a return from interrupt handler" without any return value is valuable per se because it lets the trace analyzer know when the hardirq handler ended.
e.g., if we instrument the x86 local apic irq handler only with an "irq entry" event, we would not be able to detect if the following events are nested on top of the IRQ handler or are executed in thread context.
Having those two hardirq entry/exit events is also especially useful to figure out the maximum interrupt latency caused by long interrupt handlers (or that could be many handlers hooked on the same interrupt line).
Mathieu
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |