lkml.org 
[lkml]   [2009]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [tip:perf/core] events: Rename TRACE_EVENT_TEMPLATE() to DECLARE_EVENT_CLASS()

    * Steven Rostedt <rostedt@goodmis.org> wrote:

    > On Thu, 2009-11-26 at 08:16 +0000, tip-bot for Ingo Molnar wrote:
    > > Commit-ID: 091ad3658e3c76c5fb05f65bfb64a0246f8f31b5
    > > Gitweb: http://git.kernel.org/tip/091ad3658e3c76c5fb05f65bfb64a0246f8f31b5
    > > Author: Ingo Molnar <mingo@elte.hu>
    > > AuthorDate: Thu, 26 Nov 2009 09:04:55 +0100
    > > Committer: Ingo Molnar <mingo@elte.hu>
    > > CommitDate: Thu, 26 Nov 2009 09:04:55 +0100
    > >
    > > events: Rename TRACE_EVENT_TEMPLATE() to DECLARE_EVENT_CLASS()
    > >
    > > It is not quite obvious at first sight what TRACE_EVENT_TEMPLATE
    > > does: does it define an event as well beyond defining a template?
    > >
    > > To clarify this, rename it to DECLARE_EVENT_CLASS, which follows
    > > the various 'DECLARE_*()' idioms we already have in the kernel:
    > >
    > > DECLARE_EVENT_CLASS(class)
    > >
    > > DEFINE_EVENT(class, event1)
    > > DEFINE_EVENT(class, event2)
    > > DEFINE_EVENT(class, event3)
    > >
    > > To complete this logic we should also rename TRACE_EVENT() to:
    > >
    > > DEFINE_SINGLE_EVENT(single_event)
    > >
    > > ... but in a more quiet moment of the kernel cycle.
    >
    >
    > I would like to hear what others think about this change before we go
    > ahead and implement it.

    You mean TRACE_EVENT() -> DEFINE_SINGLE_EVENT()? Sure, we want todo it
    in a more quiet moment of the kernel cycle, not now.

    (TRACE_EVENT_TEMPLATE OTOH has existed for just a few days so it's not a
    problem.)

    > A lot of developers have just learned about TRACE_EVENT and now it
    > just disappeared. Well, not really, but in the sense of ' find
    > linux.git -name '*.[ch]' | xargs grep TRACE_EVENT' it no longer
    > exists.

    A second problem with the TRACE_EVENT name is that it's not just for
    tracing - we dont necessarily 'trace' events here. We can use the event
    callbacks to collect pure counts:

    | aldebaran> perf stat -e sched:sched_wakeup ./hackbench 10
    | Time: 0.093
    |
    | Performance counter stats for './hackbench 10':
    |
    | 15481 sched:sched_wakeup
    |
    | 0.107390574 seconds time elapsed

    etc.

    A third problem is that the name 'TRACE_EVENT' does not tell us what is
    being done. Do we declare it? Do we also define it?

    DEFINE_SINGLE_EVENT() solves all these problems:

    - It's obvious what it does

    - It suggests users of it that there's another non-single-event
    facility, gently nudging them towards the use of the more efficient
    DEFINE_EVENT_CLASS() + DEFINE_EVENT() method.

    - It fits nicely into the rest of the naming scheme.

    Ingo


    \
     
     \ /
      Last update: 2009-11-26 09:43    [W:0.025 / U:1.020 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site