lkml.org 
[lkml]   [2012]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [PATCH v2] printk: add option to print cpu id
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Vikram Pandita
> Sent: Friday, August 03, 2012 2:46 PM
> To: gregkh@linuxfoundation.org; kay@vrfy.org
> Cc: linux-kernel@vger.kernel.org; Vikram Pandita; Mike Turquette; Vimarsh
> Zutshi
> Subject: [PATCH v2] printk: add option to print cpu id
>
> From: Vikram Pandita <vikram.pandita@ti.com>
>
> Introduce config option to enable CPU id reporting for printk() calls.
>
> Example logs with this option enabled look like:
> [1] [ 2.328613] usbcore: registered new interface driver libusual
> [1] [ 2.335418] usbcore: registered new interface driver usbtest
> [1] [ 2.342803] mousedev: PS/2 mouse device common for all mice
> [0] [ 2.352600] twl_rtc twl_rtc: Power up reset detected.
> [0] [ 2.359191] twl_rtc twl_rtc: Enabling TWL-RTC
> [1] [ 2.367797] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
> [1] [ 2.375274] i2c /dev entries driver
> [1] [ 2.382324] Driver for 1-wire Dallas network protocol.
>
> Its sometimes very useful to have printk also print the CPU Identifier
> that executed the call. This has helped to debug various SMP issues on
> shipping
> products.

Is it not better to have macros which will have wrapper to printk with required
debug info added? E.g. cpu# in your case.
If by default we add cupid, is it not over head in each message getting
printed with printk?

>
> Known limitation is if the system gets preempted between function call and
> actual printk, the reported cpu-id might not be accurate. But most of the
> times its seen to give a good feel of how the N cpu's in the system are
> getting loaded.
>


\
 
 \ /
  Last update: 2012-08-03 12:01    [from the cache]
©2003-2011 Jasper Spaans