Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758570AbaDXWTA (ORCPT ); Thu, 24 Apr 2014 18:19:00 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:37851 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758050AbaDXWSy (ORCPT ); Thu, 24 Apr 2014 18:18:54 -0400 Date: Thu, 24 Apr 2014 15:18:52 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Jiri Kosina cc: Greg Kroah-Hartman , =?UTF-8?Q?J=C3=B6rn_Engel?= , Rik van Riel , linux-kernel@vger.kernel.org, peterz@infradead.org, akpm@linux-foundation.org, cxie@redhat.com, Jiri Slaby Subject: Re: [PATCH] printk: Print cpu number along with time In-Reply-To: Message-ID: References: <20140423125352.704f9fb2@annuminas.surriel.com> <20140424005247.GA17713@logfs.org> <20140424194024.GA25446@logfs.org> <20140424195821.GA3092@kroah.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 25 Apr 2014, Jiri Kosina wrote: > > > +#ifdef CONFIG_PRINTK_CPU > > > + if (!buf) > > > + return snprintf(NULL, 0, "[%5lu.000000,%02x] ", > > > > %02x for a cpu? What happens on machines with 8k cpus? > > Ummm ... what issue do you see here, Greg? It'll print 0x1f40, no? > I think he's referring to the alignment with %02x. > > 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? > > Well, if you have dmesg dump from panic that happens every other year, and > you have to do post-mortem analysis on it, I am pretty sure you would love > to be able to figure out how the stack traces would look like without > inter-CPU interleaving. And I am pretty sure you wouldn't want to > insert/enable a tracepoint and wait another two years for the bug to > trigger again. > Sounds like the appropriate fix would be to serialize stack dumping to the kernel log. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/