|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Andrew Morton <akpm-AT-linux-foundation.org>|
|| ||Re: [PATCH][RFC] vsprintf: unify the format decoding layer for its
|| ||Fri, 27 Feb 2009 09:32:12 +0100|
|| ||Frederic Weisbecker <fweisbec-AT-gmail.com>,
Linus Torvalds <torvalds-AT-linux-foundation.org>,
linux-kernel-AT-vger.kernel.org, Steven Rostedt <rostedt-AT-goodmis.org>,
Lai Jiangshan <laijs-AT-cn.fujitsu.com>,
Peter Zijlstra <peterz-AT-infradead.org>|
|| ||Article, Thread
* Andrew Morton <firstname.lastname@example.org> wrote:
> On Fri, 27 Feb 2009 08:12:13 +0100 Frederic Weisbecker <email@example.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++);
> <exercise for the reader>
> 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
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
> 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
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
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.
to post comments)