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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
