From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yinghai Lu Subject: Re: [patch v2] x86: reduce srat verbosity in the kernel log Date: Tue, 10 Nov 2009 13:42:40 -0800 Message-ID: <4AF9DE50.50807@kernel.org> References: <87pr8ay6tc.fsf@basil.nowhere.org> <4AE710C9.2070307@sgi.com> <4AE75162.7080903@sgi.com> <20091028033219.GE7744@basil.fritz.box> <20091028041159.GI7744@basil.fritz.box> <20091110213312.GE23196@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from hera.kernel.org ([140.211.167.34]:44196 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758263AbZKJVog (ORCPT ); Tue, 10 Nov 2009 16:44:36 -0500 In-Reply-To: <20091110213312.GE23196@elte.hu> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Ingo Molnar Cc: David Rientjes , Mike Travis , Thomas Gleixner , Andrew Morton , Jack Steiner , "H. Peter Anvin" , x86@kernel.org, Mel Gorman , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, Andi Kleen Ingo Molnar wrote: > * David Rientjes wrote: > >> On Tue, 27 Oct 2009, David Rientjes wrote: >> >>> x86: reduce srat verbosity in the kernel log >>> >>> It's possible to reduce the number of SRAT messages emitted to the kernel >>> log by printing each valid pxm once and then creating bitmaps to represent >>> the apic ids that map to the same node. >>> >>> This reduces lines such as >>> >>> SRAT: PXM 0 -> APIC 0 -> Node 0 >>> SRAT: PXM 0 -> APIC 1 -> Node 0 >>> SRAT: PXM 1 -> APIC 2 -> Node 1 >>> SRAT: PXM 1 -> APIC 3 -> Node 1 >>> >>> to >>> >>> SRAT: PXM 0 -> APIC {0-1} -> Node 0 >>> SRAT: PXM 1 -> APIC {2-3} -> Node 1 >>> >>> The buffer used to store the apic id list is 128 characters in length. >>> If that is too small to represent all the apic id ranges that are bound >>> to a single pxm, a trailing "..." is added. APICID_LIST_LEN should be >>> manually increased for such configurations. >>> >>> Acked-by: Mike Travis >>> Signed-off-by: David Rientjes >> Ingo, have you had a chance to look at merging this yet? > > I'm waiting for Mike to test them (and other patches) and send a new > series out with bits to pick up. > > But i really dont like such type of buffering - in the past they tended > to be problematic. Why print this info at all in the default bootup? > It's not needed on a correctly functioning system. > > For failure analysis make it opt-in available via a boot parameter (if > it's needed for bootup analysis) - but otherwise just dont print it. > make them to depend on apic=debug or apic=verbose? YH