[lkml]   [2009]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][RFC] vsprintf: unify the format decoding layer for its 3 users

* Andrew Morton <> wrote:

> On Fri, 27 Feb 2009 09:32:12 +0100 Ingo Molnar <> 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

... 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().


 \ /
  Last update: 2009-02-27 10:39    [W:0.044 / U:3.724 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site