Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752896AbZJZSSj (ORCPT ); Mon, 26 Oct 2009 14:18:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752728AbZJZSSi (ORCPT ); Mon, 26 Oct 2009 14:18:38 -0400 Received: from relay3.sgi.com ([192.48.152.1]:56693 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752691AbZJZSSh (ORCPT ); Mon, 26 Oct 2009 14:18:37 -0400 Message-ID: <4AE5E804.9060409@sgi.com> Date: Mon, 26 Oct 2009 11:18:44 -0700 From: Mike Travis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Dmitry Adamushko CC: Ingo Molnar , Thomas Gleixner , Andrew Morton , Jack Steiner , Tigran Aivazian , "H. Peter Anvin" , x86@kernel.org, Andreas Mohr , Hugh Dickins , Hannes Eder , linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/8] SGI x86_64 UV: Limit the number of microcode messages References: <20091023233743.439628000@alcatraz.americas.sgi.com> <20091023233756.941535000@alcatraz.americas.sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2098 Lines: 58 Dmitry Adamushko wrote: > 2009/10/24 Mike Travis : >> Limit number of microcode messages of the form: >> >> [ 50.887135] microcode: CPU0 sig=0x206e5, pf=0x4, revision=0xffff001 >> >> [ ... ] >> >> --- linux.orig/arch/x86/kernel/microcode_intel.c >> +++ linux/arch/x86/kernel/microcode_intel.c >> @@ -165,7 +165,9 @@ >> /* get the current revision from MSR 0x8B */ >> rdmsr(MSR_IA32_UCODE_REV, val[0], csig->rev); >> >> - printk(KERN_INFO "microcode: CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n", >> + if (cpu_num < 4 || !limit_console_output(false)) >> + printk(KERN_INFO >> + "microcode: CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n", >> cpu_num, csig->sig, csig->pf, csig->rev); >> > > Hmm, I guess we wouldn't lose a lot by simply removing those messages > completely. Per-cpu pf/revision is available via /sys anyway. > > Alternatively, we might move the output into > microcode_core.c::collect_cpu_info() (or even microcode_init_cpu()) so > that the same logic is also applied for amd and do something as > following: > > don't print if a cpu info is equal to the info of CPU#0. I guess, any > non-0 cpu would be even better as the microcode for cpu#0 can be > loaded by BIOS, if I'm not mistaken. But then we can only be sure > about the presence of cpu#0. > > Anyway, it's not worthy of any additional complexity so I'd say let's > just remove the output :-) > > > -- Dmitry I would be more than happy to remove messages but I didn't want to override the original author's intent on why they choose to add these messages in the first place. Plus if you have a 64 or 128 cpu system, it might give you pleasure in seeing all those cpu messages. ;-) Just when it hits around 256 and up that it really starts getting annoying. Thanks, Mike -- 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/