Messages in this thread | | | Subject | Re: [PATCH 05/10][RFC] tracing: Move fields from event to class structure | From | Steven Rostedt <> | Date | Wed, 28 Apr 2010 20:02:22 -0400 |
| |
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
| |