Re: [PATCH][RFC] vsprintf: unify the format decoding layer for its 3 users

[Ingo Molnar <mingo@elte.hu>]

* 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