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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Feb 2009 00:33:30 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
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

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

> 
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> > On Fri, 27 Feb 2009 07:19:37 +0100 Frederic Weisbecker <fweisbec@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/