Messages in this thread | | | From | "Pandita, Vikram" <> | Date | Fri, 3 Aug 2012 02:56:02 -0700 | Subject | Re: [PATCH v2] printk: add option to print cpu id |
| |
Kay
On Fri, Aug 3, 2012 at 2:48 AM, Kay Sievers <kay@vrfy.org> wrote: > On Fri, Aug 3, 2012 at 11:36 AM, Pandita, Vikram <vikram.pandita@ti.com> wrote: >> On Fri, Aug 3, 2012 at 2:32 AM, Venu Byravarasu <vbyravarasu@nvidia.com> wrote: > >>> As having Macro locally in the file of interest would serve the purpose, >>> Why to change the printk code? >> >> As stated, the logic followed is exactly similar to well proven and >> approved way to handle printk time stamp: CONFIG_PRINTK_TIME >> Its an overhead on the system that enables the config option: >> CONFIG_PRINTK_CPUID >> Otherwise the system remains as is. >> >> To gain insight on SMP system logging behavior, the price to pay is >> the extra 4 chars per printk line, >> just like printk-time adds 15 chars to each line. Both options can be >> disabled as desired. >> >> So i am not sure what kind of option you are proposing? >> Do u imply PRINTK_TIME is not right then? > > It's 8 bytes per message for storing the timestamp in the records. > There is never 15 bytes storage space needed, the prefix is > constructed on-the-fly only while exporting the data.
When i was referring to 15 chars, its coming from here: Its the space reserved in each line of output. Corresponding space for cpuid is 4 chars: "[x] ":
static size_t print_time(u64 ts, char *buf) { unsigned long rem_nsec;
if (!printk_time) return 0;
if (!buf) >>>> return 15;
> > The CPU-ID would need at least two additional bytes (2^16 CPUS) in > every record, unless it's a compile-time option.
are u proposing: a) to make cpuid a u16? b) to put cpuid in struct cont and struct log - under the #ifdef macro?
> I can't tell, if > everybody wants to pay the storage space for the the CPU-ID feature. > > Kay
| |