Messages in this thread | | | Subject | RE: [PATCH v9 3/3] trace,x86: code-sharing between non-trace and trace irq handlers | From | "H. Peter Anvin" <> | Date | Fri, 15 Feb 2013 21:39:56 -0800 |
| |
Fair enough. Sounds good.
Seiji Aguchi <seiji.aguchi@hds.com> wrote:
>> > 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
-- Sent from my mobile phone. Please excuse brevity and lack of formatting.
| |