lkml.org 
[lkml]   [2010]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 05/10][RFC] tracing: Move fields from event to class structure
    From
    Date
    On Wed, 2010-04-28 at 16:58 -0400, Mathieu Desnoyers wrote:
    > * Steven Rostedt (rostedt@goodmis.org) wrote:
    > > From: Steven Rostedt <srostedt@redhat.com>
    > >
    > > Move the defined fields from the event to the class structure.
    > > Since the fields of the event are defined by the class they belong
    > > to, it makes sense to have the class hold the information instead
    > > of the individual events. The events of the same class would just
    > > hold duplicate information.
    > >
    > > After this change the size of the kernel dropped another 8K:
    > >
    > > text data bss dec hex filename
    > > 5788186 1337252 9351592 16477030 fb6b66 vmlinux.orig
    > > 5774316 1306580 9351592 16432488 fabd68 vmlinux.reg
    > > 5774503 1297492 9351592 16423587 fa9aa3 vmlinux.fields
    > >
    > > Although the text increased, this was mainly due to the C files
    > > having to adapt to the change. This is a constant increase, where
    > > new tracepoints will not increase the Text. But the big drop is
    > > in the data size (as well as needed allocations to hold the fields).
    > > This will give even more savings as more tracepoints are created.
    > >
    > > Note, if just TRACE_EVENT()s are used and not DECLARE_EVENT_CLASS()
    > > with several DEFINE_EVENT()s, then the savings will be lost. But
    > > we are pushing developers to consolidate events with DEFINE_EVENT()
    > > so this should not be an issue.
    > >
    > > The kprobes define a unique class to every new event, but are dynamic
    > > so it should not be a issue.
    > >
    > > The syscalls however have a single class but the fields for the individual
    > > events are different. The syscalls use a metadata to define the
    > > fields. I moved the fields list from the event to the metadata and
    > > added a "get_fields()" function to the class. This function is used
    > > to find the fields. For normal events and kprobes, get_fields() just
    > > returns a pointer to the fields list_head in the class. For syscall
    > > events, it returns the fields list_head in the metadata for the event.
    >
    > So, playing catch-up here, why don't we simply put each syscall event in
    > their own class ? We could possibly share the class where it makes
    > sense (e.g. exact same fields).

    Well, they have their own class. But I guess you are talking about a
    "meta-data class".

    >
    > With the per-class sub-metadata, what's the limitations we have to
    > expect with these system call events ? Can we map to a field size
    > directly from the event ID, or do we have to somehow have the event size
    > encoded in the header to make sense of the payload ?

    That will be a lot of work. This is all generated automatically from the
    SYSCALL() macros. To group them, we need a way to know what syscalls
    have the same parameters, and manually add that. It may end up being a
    maintenance nightmare.

    -- Steve




    \
     
     \ /
      Last update: 2010-04-29 02:05    [W:0.033 / U:0.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site