Messages in this thread | | | Date | Fri, 27 Feb 2009 10:35:31 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH][RFC] vsprintf: unify the format decoding layer for its 3 users |
| |
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 27 Feb 2009 09:32:12 +0100 Ingo Molnar <mingo@elte.hu> wrote: > > > a printf variant that outputs not into a string buffer but > > into a binary-values buffer. > > Oh, OK. > > Of course, parsing a printf string (using our > nobody-bothered-optimising-it parser) isn't particularly > efficient either. > > Is there a case here for adding a new way of describing how to > serialise the incoming data? Perhaps with a new and simpler > control string or perhaps even > > struct ftrace_thing ft; > > init_ftrace_thing(&ft, "%d %l %s"); > add_ftrace_thing_int(&ft, some_int); > add_ftrace_thing_long(&ft, some_long); > add_ftrace_thing_string(&ft, some_string); > emit_ftrace_thing(&ft); > > or some similar thing.
Maybe - but i think it misses the main point.
If we care about a tracepoint from a performance POV we wont use printf. When it comes to raw performance then we already have direct, non-string ways of describing data: the C language and function calls straight to a tracepoint function. No "inbetween" solution will be able to beat that.
The beauty (and pretty much only point) of trace_printk() is the convenience of the well-known printf usage. It might be slow to parse but it is what we are using in:
earth4:~/tip> git grep printk | wc -l 68603
... tens of thousands of places in the kernel.
We could invent something inbetween but why? We wont be able to beat the performance of tracepoints that leave out the format string middle-man, and we dont want to.
So what Lai and Frederic is trying is to offer a transparent speedup for trace_printk().
Ingo
| |