Date:	Fri, 27 Feb 2009 09:32:12 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH][RFC] vsprintf: unify the format decoding layer for its
	3 users


* Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Fri, 27 Feb 2009 08:12:13 +0100 Frederic Weisbecker <fweisbec@...il.com> wrote:
> 
> > > Why does the current ftrace_bprintk() need to hack around in (or
> > > duplicate) vprintk() internals?  It's a bit grubby, but by placing an
> > > upper bound on the number of args, it could simply call vscnprintf()
> > > directly?
> > >
> > 
> > The problem is more in the way to save the parameters.
> > 
> > You have two functions:
> > 
> > _int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args)
> > 
> > 
> > This one creates a compact binary packet of all args described in the format.
> > The result is a binary set of random values on bin_buf.
> > 
> > 
> > _int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf)
> > 
> > 
> > This one lately parses the buffer filled by vbin_printf() and eventually format
> > this binary contiguous set of binary values according to the format in fmt (which is the
> > same that was passed to vbin_printf()
> > The result is formatted in buf.
> > 
> > vbin uses too much specific write-to-bin_buf operations to 
> > allow us to wrap vsnprintf()
> 
> I don't know what vbin is.

a printf variant that outputs not into a string buffer but into 
a binary-values buffer. See earlier mails in this same thread. 
(I Cc:-ed you mid-thread on the assumption that you might be 
interested - but you need to look into the lkml folder to see 
all the context.)

> On little-endian architecture you could do something like
> 
> 	u32 *p = bin_buf;
> 	char *fmt;
> 	u32 a0, a1, a2, a3, a4;
> 
> #ifdef CONFIG_32BIT
> 	fmt = (char *)(*bin_buf++);
> #else
> 	<exercise for the reader>
> #endif
> 
> 	a0 = *bin_buf++;
> 	a1 = *bin_buf++;
> 	a2 = *bin_buf++;
> 	a3 = *bin_buf++;
> 	a4 = *bin_buf++;
> 
> 	snprintf(somewhere, some_size, fmt, a0, a1, a2, a3, a4, a5);
> 
> (as I said, ugly).

Yes, and slow as well. This isnt new functionality - this is 
about speedups, using the format string as a data types 
descriptor.

The goal is to get the speedup that Frederic cited:

  ftrace_printk:  duration average: 8812 ns
  ftrace_bprintk: duration average: 2611 ns

The _fastest_ way of tracing is obviously to know about the 
precise argument layout and having a specific C based tracepoint 
stub that directly stuffs that data into the ring buffer. Most 
tracepoints are of such nature.

That does not remove the ease of use of ad-hoc printk-alike 
tracepoints though, and speeding them up 3-fold is a worthwile 
goal.

> but that won't work for 64-bit values on big-endian 
> architectures.  And it's hacky (and might not even work) for 
> 64-bit on little endian.
> 
> Perhaps this is the secret problem which you haven't described 
> yet?

The first submission was a completely standalone implementations 
not touching vsnprintf at all. I suggested to Frederic to try to 
generalize it, to reduce code duplication. That's why this patch 
touches vsnprintf.

We can do it all in kernel/trace/trace.c if the lib/vsnprintf.c 
bits turn out to be ugly or not useful enough. We just thought 
we'd try to make this more generally useful before stuffing it 
into a specific subsystem.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists