Re: [PATCH] stop ==== emergency

[Hugh Dickins <hugh@veritas.com>]

On Mon, 6 Feb 2006, Jean Delvare wrote:
> 
> However, given that printk calls aren't exactly cheap, don't we want to
> merge them where possible?
> 
> --- linux-2.6.16-rc2.orig/arch/i386/kernel/traps.c	2006-02-06 07:50:57.000000000 +0100
> +++ linux-2.6.16-rc2/arch/i386/kernel/traps.c	2006-02-06 19:42:10.000000000 +0100
> @@ -114,8 +114,7 @@
>  
>  static void print_addr_and_symbol(unsigned long addr, char *log_lvl)
>  {
> -	printk(log_lvl);
> -	printk(" [<%08lx>] ", addr);
> +	printk("%s [<%08lx>] ", log_lvl, addr);
> ....
> 
> More merges are possible, but I'm not sure how far we want to go.

I assumed, as I guess Chuck who put in all the printk(log_lvl)s did,
that they wouldn't be deciphered right if as separate args.  But a
glance at vprintk suggests you're right, they're interpreted after
expanding into printk_buf.

But my own interest in minimizing printk calls is rather low at the
moment; and they're hardly time-critical, are they? fast paths won't
be fast if they're doing printk's, and I hope things haven't got so
bad that we need dump_stack to be fast!  Waste more space? expect so.

More important would be: how's the SMP printk behaviour these days?
Does separating log_lvl from message increase the likelihood that the
log_lvls might be misapplied if different CPUs print at the same time?
If so, then I'd say your changes are very important - but please send
them to Andrew rather than to me.

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