Re: [PATCH 2/9] tracing: Convert some kmem events to DEFINE_EVENT

[Ingo Molnar <mingo@elte.hu>]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> Li Zefan kirjoitti:
> >Use TRACE_EVENT_TEMPLATE to remove duplicate code:
> >
> >   text    data     bss     dec     hex filename
> > 333987   69800   27228  431015   693a7 mm/built-in.o.old
> > 330030   69800   27228  427058   68432 mm/built-in.o
> >
> >8 events are converted:
> >
> >  kmem_alloc: kmalloc, kmem_cache_alloc
> >  kmem_alloc_node: kmalloc_node, kmem_cache_alloc_node
> >  kmem_free: kfree, kmem_cache_free
> >  mm_page: mm_page_alloc_zone_locked, mm_page_pcpu_drain
> >
> >Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> 
> I have no idea what TRACE_EVENT_TEMPLATE is [...]

See these recent commits in tip:perf/core:

 75ec29a: tracing: Convert some sched trace events to DEFINE_EVENT and _PRINT
 e5bc972: tracing: Create new DEFINE_EVENT_PRINT
 ff038f5: tracing: Create new TRACE_EVENT_TEMPLATE

This introduces the new TRACE_EVENT_TEMPLATE + DEFINE_EVENT construct 
that allows one to 'clone' existing tracepoints into a new tracepoint 
that have the same parameters/format but differing callsites.

The existing TRACE_EVENT construct is there too (unchanged), it's 
equivalent to TRACE_EVENT_TEMPLATE()+DEFINE_EVENT().

It basically introduces a 'class'/'template' of tracepoints - which can 
then be used to create real tracepoints.

Btw., the fact that it wasnt entirely obvious for you from the patch 
what it does, there's one rename we should do, to have more consistent 
and more self-explanatory naming:

  DECLARE_EVENT_CLASS(class)

    DEFINE_EVENT(class, event1)
    DEFINE_EVENT(class, event2)
    DEFINE_EVENT(class, event3)

  DEFINE_SINGLE_EVENT(single_event)

Naming the 'standalone' variant like that signals this difference and 
encourages people to create classes/groups of events instead of creating 
many singular events.

> [...] but the space savings are convincing enough! I assume this is 
> going into -tip?

Yeah, tip:perf/core, with your ack.

> Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>

Thanks,

	Ingo