Messages in this thread | | | From | Venu Byravarasu <> | Date | Fri, 3 Aug 2012 14:57:42 +0530 | Subject | RE: [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. >
| |