linux-kernel - Re: [PATCH v3] printk: add option to print cpu id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFm5wm3ScpUU5wa=ei3TY0zjU4kVbOgJMmE5_QDpwy7B-TJa+A@mail.gmail.com>
Date:	Fri, 3 Aug 2012 11:25:37 -0700
From:	"Pandita, Vikram" <vikram.pandita@...com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	gregkh@...uxfoundation.org, kay@...y.org,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Mike Turquette <mturquette@...aro.org>,
	Vimarsh Zutshi <vimarsh.zutshi@...il.com>
Subject: Re: [PATCH v3] printk: add option to print cpu id

On Fri, Aug 3, 2012 at 10:54 AM, Andi Kleen <andi@...stfloor.org> wrote:
> Vikram Pandita <vikram.pandita@...com> writes:
>
>> From: Vikram Pandita <vikram.pandita@...com>
>>
>> Introduce config option to enable CPU id reporting for printk() calls.
>
> What's wrong with using trace_printk for this?

trace_printk works only when you know the _exact_ path in code that
you want to profile.
When you have no idea of a random lockup, then it would be kind of
touch and time consuming
to put trace prints all around the code.

> That's much faster
> anyways. Generally printk is so slow that it's typically useless for
> instrumenting races.
>

As stated in another thread, its found useful to debug some specific cases:
Check thread: http://marc.info/?l=linux-omap&m=134401269106619&w=2

> And really: Wasting 1/3 of the 80 character line is too much.

You _WASTE_ 4 chars only if you are interested in this info by
enabling: CONFIG_PRINTK_CPUID
Just like you _WASTE_ 15 chars when you enable existing: CONFIG_PRINTK_TIME

For general usecase, recommendation would be to keep these options disabled.
Working on shipping products, i find almost all shipping with
CONFIG_PRINTK_TIME enabled, so there must be some value.
Same would hold for the use case being debugged for CPUID enabling.

>
> -Andi
>
> --
> ak@...ux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/