On Fri, 13 Jul 2012, Seiji Aguchi wrote:
> Thomas,
>
> Any comment?
Yes :)
> > > +DECLARE_EVENT_CLASS(irq_vector,
> > > +
> > > + TP_PROTO(int irq),
> > > +
> > > + TP_ARGS(irq),
> > > +
> > > + TP_STRUCT__entry(
> > > + __field( int, irq )
Shouldn't this be vector?
> > > +DEFINE_EVENT(irq_vector, nmi_entry,
> > > +DEFINE_EVENT(irq_vector, nmi_exit,
> > > +DEFINE_EVENT(irq_vector, local_timer_entry,
> > > +DEFINE_EVENT(irq_vector, local_timer_exit,
> > > +DEFINE_EVENT(irq_vector, reschedule_entry,
> > > +DEFINE_EVENT(irq_vector, reschedule_exit,
> > > +DEFINE_EVENT(irq_vector, call_function_entry,
> > > +DEFINE_EVENT(irq_vector, call_function_exit,
> > > +DEFINE_EVENT(irq_vector, call_function_single_entry,
> > > +DEFINE_EVENT(irq_vector, call_function_single_exit,
> > > +DEFINE_EVENT(irq_vector, irq_work_entry,
> > > +DEFINE_EVENT(irq_vector, irq_work_exit,
> > > +DEFINE_EVENT(irq_vector, invalidate_tlb_entry,
> > > +DEFINE_EVENT(irq_vector, invalidate_tlb_exit,
So this set is pretty generic and applicable across
architectures. Good.
> > > +DEFINE_EVENT(irq_vector, error_apic_entry,
> > > +DEFINE_EVENT(irq_vector, error_apic_exit,
> > > +DEFINE_EVENT(irq_vector, thermal_apic_entry,
> > > +DEFINE_EVENT(irq_vector, thermal_apic_exit,
> > > +DEFINE_EVENT(irq_vector, threshold_apic_entry,
> > > +DEFINE_EVENT(irq_vector, threshold_apic_exit,
> > > +DEFINE_EVENT(irq_vector, spurious_apic_entry,
> > > +DEFINE_EVENT(irq_vector, spurious_apic_exit,
> > > +DEFINE_EVENT(irq_vector, x86_platform_ipi_entry,
> > > +DEFINE_EVENT(irq_vector, x86_platform_ipi_exit,
That part is x86 specific. If we go that route, we'll end up with
gazillions of arch specific vectors sooner than later.
Either we find better and more widely applicable names for them, if
there are similar functionalities on other architectures available, or
we should have a single generic tracepoint for those which cannot be
be mapped to anything useful shared across architectures.
Those x86 specific ones are not really frequently raised vectors, so
enabling them all won't affect performance and readability of the
traces too much.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
