All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Jörn Engel" <joern@logfs.org>
Cc: Jiri Kosina <jkosina@suse.cz>, Rik van Riel <riel@redhat.com>,
	linux-kernel@vger.kernel.org, peterz@infradead.org,
	akpm@linux-foundation.org, cxie@redhat.com,
	Jiri Slaby <jslaby@suse.cz>
Subject: Re: [PATCH] printk: Print cpu number along with time
Date: Thu, 24 Apr 2014 12:58:21 -0700	[thread overview]
Message-ID: <20140424195821.GA3092@kroah.com> (raw)
In-Reply-To: <20140424194024.GA25446@logfs.org>

On Thu, Apr 24, 2014 at 03:40:24PM -0400, Jörn Engel wrote:
> On Wed, 23 April 2014 20:52:47 -0400, Jörn Engel wrote:
> > 
> > I use the patch below for some time now.  While it doesn't avoid the
> > log pollution in the first place, it lessens the impact somewhat.
> 
> Added a config option and ported it to current -linus.  Andrew, would
> you take this patch?
> 
> ---
> 
> Sometimes the printk log is heavily interleaving between different cpus.
> This is particularly bad when you have two backtraces at the same time,
> but can be annoying in other cases as well.  With an explicit cpu
> number, a simple grep can disentangle the mess for you.
> 
> Signed-off-by: Joern Engel <joern@logfs.org>
> ---
>  kernel/printk/printk.c | 19 ++++++++++++++++---
>  lib/Kconfig.debug      |  9 +++++++++
>  2 files changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index a45b50962295..b9e464924825 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -200,6 +200,7 @@ struct printk_log {
>  	u16 len;		/* length of entire record */
>  	u16 text_len;		/* length of text buffer */
>  	u16 dict_len;		/* length of dictionary buffer */
> +	u16 cpu;		/* cpu the message was generated on */
>  	u8 facility;		/* syslog facility */
>  	u8 flags:5;		/* internal record flags */
>  	u8 level:3;		/* syslog level */
> @@ -346,6 +347,7 @@ static void log_store(int facility, int level,
>  	msg->facility = facility;
>  	msg->level = level & 7;
>  	msg->flags = flags & 0x1f;
> +	msg->cpu = smp_processor_id();
>  	if (ts_nsec > 0)
>  		msg->ts_nsec = ts_nsec;
>  	else
> @@ -859,7 +861,7 @@ static bool printk_time;
>  #endif
>  module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
>  
> -static size_t print_time(u64 ts, char *buf)
> +static size_t print_time(u64 ts, u16 cpu, char *buf)
>  {
>  	unsigned long rem_nsec;
>  
> @@ -868,11 +870,20 @@ static size_t print_time(u64 ts, char *buf)
>  
>  	rem_nsec = do_div(ts, 1000000000);
>  
> +#ifdef CONFIG_PRINTK_CPU
> +	if (!buf)
> +		return snprintf(NULL, 0, "[%5lu.000000,%02x] ",

%02x for a cpu?  What happens on machines with 8k cpus?

And is this really an issue?  Debugging by using printk is fun, but not
really something that people need to add a cpu number to.  Why not just
use a tracepoint in your code to get the needed information instead?

thanks,

greg k-h

  reply	other threads:[~2014-04-24 19:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23 16:53 [PATCH RFC] sysrq: rcu-ify __handle_sysrq Rik van Riel
2014-04-23 20:04 ` Andrew Morton
2014-04-23 20:44   ` Rik van Riel
2014-04-23 21:39   ` Jiri Kosina
2014-04-23 21:41     ` Andrew Morton
2014-04-23 21:44       ` Jiri Kosina
2014-04-23 21:49         ` Andrew Morton
2014-04-23 21:37 ` Jiri Kosina
2014-04-23 21:42   ` Rik van Riel
2014-04-23 21:51     ` Jiri Kosina
2014-04-24  1:46       ` Paul E. McKenney
2014-04-24 13:04         ` [PATCH RFC] sysrq,rcu: suppress RCU stall warnings while sysrq runs Rik van Riel
2014-04-24 15:16           ` Paul E. McKenney
2014-04-25  5:35           ` Mike Galbraith
2014-04-24  0:52   ` [PATCH RFC] sysrq: rcu-ify __handle_sysrq Jörn Engel
2014-04-24 19:40     ` [PATCH] printk: Print cpu number along with time Jörn Engel
2014-04-24 19:58       ` Greg Kroah-Hartman [this message]
2014-04-24 21:23         ` Jörn Engel
2014-04-24 22:12         ` Jiri Kosina
2014-04-24 22:18           ` David Rientjes
2014-04-24 22:21             ` Jiri Kosina
2014-04-24 23:29               ` Jörn Engel
2014-04-24 22:20           ` Greg Kroah-Hartman
2014-04-28 23:40       ` Jörn Engel
2014-04-29  0:22         ` Andrew Morton
2014-06-04 23:15           ` Jörn Engel
2014-06-04 23:28             ` Andrew Morton
2014-06-04 23:49               ` Jörn Engel
2014-09-09 17:16             ` Jörn Engel
2014-09-10 21:26               ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140424195821.GA3092@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=cxie@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=joern@logfs.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.