> -----Original Message----- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Vikram Pandita > Sent: Friday, August 03, 2012 2:46 PM > To: gre...@linuxfoundation.org; k...@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.pand...@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. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
