linux-kernel - Re: [PATCH] x86_64: Limit the number of processor bootup messages

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: <20091112222200.GA19109@redhat.com>
Date:	Thu, 12 Nov 2009 17:22:01 -0500
From:	Dave Jones <davej@...hat.com>
To:	Mike Travis <travis@....com>
Cc:	Andi Kleen <ak@...ux.intel.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Roland Dreier <rdreier@...co.com>,
	Randy Dunlap <rdunlap@...otime.net>, Tejun Heo <tj@...nel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Rientjes <rientjes@...gle.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	Jack Steiner <steiner@....com>,
	Frederic Weisbecker <fweisbec@...il.com>, x86@...nel.org,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86_64: Limit the number of processor bootup messages

On Mon, Nov 02, 2009 at 11:21:39AM -0800, Mike Travis wrote:
 
 > >>     [   90.981402] CPU: L1 I cache: 32K, L1 D cache: 32K
 > >>     [   90.985888] CPU: L2 cache: 256K
 > >>     [   90.988032] CPU: L3 cache: 24576K
 > > 
 > > I would recommend to drop the cache information; this can be easily
 > > gotten at runtime and is often implied in the CPU name anyways
 > > (and especially L1 and increasingly L2 too change only very rarely)
 > 
 > Ok, though because of future system upgrades to a UV system, you can
 > end up with slightly different processors (of the same family).  The
 > only differences I've detected so far in testing is the stepping has
 > changed.

I happened to be annoyed by dozens of these three printk's earlier,
and hacked up the following (currently untested) patch.

But I don't disagree with Andi either, that it's not particularly useful,
and we can get all this from userspace in /proc/cpuinfo, or x86info.

If someone still finds it valuable to have the kernel keep printing it
though, perhaps something like the following ?

	Dave



On processors with a large number of cores, we print dozens of lines of information about
the CPU cache topology, most of which is unnecessary.
This patch reduces spew a lot (down to a single line unless someone uses a mix of processors
with different cache sizes)

- Check if the total cache size on APs is equal to the boot processors cache size.
  Print nothing if equal.
- The three printk's will fit on one line.

Signed-off-by: Dave Jones <davej@...hat.com>

diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 804c40e..cc4f44d 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -358,9 +362,9 @@ unsigned int __cpuinit init_intel_cacheinfo(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_HT
 	unsigned int cpu = c->cpu_index;
 #endif
+	static int is_initialized;
 
 	if (c->cpuid_level > 3) {
-		static int is_initialized;
 
 		if (is_initialized == 0) {
 			/* Init num_cache_leaves from boot CPU */
@@ -488,6 +492,21 @@ unsigned int __cpuinit init_intel_cacheinfo(struct cpuinfo_x86 *c)
 #endif
 	}
 
+	c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
+
+	/*
+	 * cache topology on all AP's is likely equal to that of the BP
+	 * if this is the case, don't bother printing anything out for the AP's.
+	 */
+	if (is_initialized != 0) {
+		if (c->x86_cache_size == boot_cpu_data.x86_cache_size)
+			return l2;
+		else
+			printk(KERN_INFO "CPU: AP has different cache size (%d) to BP (%d)\n",
+				c->x86_cache_size,
+				boot_cpu_data.x86_cache_size);
+	}
+
 	if (trace)
 		printk(KERN_INFO "CPU: Trace cache: %dK uops", trace);
 	else if (l1i)
@@ -495,16 +512,12 @@ unsigned int __cpuinit init_intel_cacheinfo(struct cpuinfo_x86 *c)
 
 	if (l1d)
 		printk(KERN_CONT ", L1 D cache: %dK\n", l1d);
-	else
-		printk(KERN_CONT "\n");
 
 	if (l2)
-		printk(KERN_INFO "CPU: L2 cache: %dK\n", l2);
+		printk(KERN_CONT ", L2 cache: %dK\n", l2);
 
 	if (l3)
-		printk(KERN_INFO "CPU: L3 cache: %dK\n", l3);
-
-	c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
+		printk(KERN_CONT ", L3 cache: %dK\n", l3);
 
 	return l2;
 }
--
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/