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 10:35:31 +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 09:32:12 +0100 Ingo Molnar <mingo@...e.hu> 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
  68603

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

	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/