Messages in this thread | | | From | Seiji Aguchi <> | Subject | RE: [PATCH v9 3/3] trace,x86: code-sharing between non-trace and trace irq handlers | Date | Sat, 16 Feb 2013 05:18:53 +0000 |
| |
> > How important is it that the tracepoint is *inside* the enter/exit > > handling? If not, it would be simpler to just do: > > > > smp_trace_irq_handler() > > { > > trace_irq_entry(); > > smp_irq_handler(); > > trace_irq_exit(); > > } > > > > ... which seems a bit cleaner. If this isn't possible, then this > > patch is fine, but please add to the patch description why the simple > > wrapper isn't doable. > > The problem is with irq_enter/exit() being called. They must be called before trace_irq_enter/exit(), because of the rcu_irq_enter() > must be called before any tracepoints are used, as tracepoints use rcu to synchronize. >
I tried to place tracepoints outside the enter/exit handling. But it didn't work because of the rcu_irq_enter().
> Now perhaps we could do this and have trace_irq_entry(). > > Not only that, the tracepoint callbacks expect irq_enter() to already be called. > > Hmm, if irq_enter() can nest, which I think it can, perhaps we can call > irq_enter() first. I'm not sure if that will screw up the second > irq_entry() inside smp_irq_handler(). > > smp_trace_irq_hander() > { > irq_entry(); > trace_irq_entry(); > smp_irq_handler(); > trace_irq_exit(); > irq_exit(); > }
If irq_enter() is nested, it may have a time penalty because it has to check if it was already called or not. It doesn't satisfy a goal of this patch. Therefore, I think current coding is reasonable.
I will update the patch description.
Seiji
| |