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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Nov 2009 22:33:12 +0100 From: Ingo Molnar <mingo@...e.hu> To: David Rientjes <rientjes@...gle.com> Cc: Mike Travis <travis@....com>, Thomas Gleixner <tglx@...utronix.de>, Andrew Morton <akpm@...ux-foundation.org>, Jack Steiner <steiner@....com>, "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org, Yinghai Lu <yinghai@...nel.org>, Mel Gorman <mel@....ul.ie>, linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org, Andi Kleen <andi@...stfloor.org> Subject: Re: [patch v2] x86: reduce srat verbosity in the kernel log * David Rientjes <rientjes@...gle.com> 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 <travis@....com> > > Signed-off-by: David Rientjes <rientjes@...gle.com> > > 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. Ingo -- 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/
Powered by blists - more mailing lists