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

[Andrew Morton]

On Fri, 27 Feb 2009 09:20:35 +0100 Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Fri, 27 Feb 2009 07:19:37 +0100 Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
> > 
> > > An new optimization is making its way to ftrace. Its purpose 
> > > is to make ftrace_printk() consuming less memory and be 
> > > faster.
> > > 
> > > Written by Lai Jiangshan, the approach is to delay the 
> > > formatting job from tracing time to output time. Currently, 
> > > a call to ftrace_printk will format the whole string and 
> > > insert it into the ring buffer.
> > 
> > It does that?  eek.
> 
> hm, did you expect something else from a printf based interface?
> 

Well, it's very obvious that it will be very slow.  We've never had any
motivation for caring about the performance of the printf functions
because they're called so infrequently.

I mean...  the whole thing's designed to fail, really - if we care
about the performance impact of tracing, we can't trace with per-tracepoint
printf()s.  If we don't care about the performance impact of tracing
then fine, leave ftrace_printk() as it is - slow.

Trying to make something which is inherently slow run slightly faster seems... 
odd.


Oh well, that's beside the point.  Right now I'm trying to provoke you
guys into revealing what the implementation problems are, and what
you're proposing to do.  Stuff like: how will it work with 64-bit
quantities on arm/s390/etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/