From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757137AbbIXPr1 (ORCPT ); Thu, 24 Sep 2015 11:47:27 -0400 Received: from mail.skyhub.de ([78.46.96.112]:58235 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754410AbbIXPrZ (ORCPT ); Thu, 24 Sep 2015 11:47:25 -0400 Date: Thu, 24 Sep 2015 17:47:22 +0200 From: Borislav Petkov To: Ashok Raj Cc: linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, Tony Luck Subject: Re: [Patch V1 1/3] x86, mce: MCE log size not enough for high core parts Message-ID: <20150924154722.GD3774@pd.tnic> References: <1443073720-3940-1-git-send-email-ashok.raj@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1443073720-3940-1-git-send-email-ashok.raj@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 24, 2015 at 01:48:38AM -0400, Ashok Raj wrote: > MCE_LOG_LEN appears to be short for high core count parts. Especially when > handling fatal errors, we don't clear MCE banks. Socket level MC banks > are visible to all CPUs that share banks. > > Assuming 18 core part, 2 threads per core 2 banks per thread and couple uncore > MSRs. Rounding to 128 with some fudge to grow in future. > > Signed-off-by: Ashok Raj > Suggested-by: Tony Luck > --- > arch/x86/include/asm/mce.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h > index 2dbc0bf..4293ae7 100644 > --- a/arch/x86/include/asm/mce.h > +++ b/arch/x86/include/asm/mce.h > @@ -88,7 +88,7 @@ > #define MCE_EXTENDED_BANK 128 > #define MCE_THERMAL_BANK (MCE_EXTENDED_BANK + 0) > > -#define MCE_LOG_LEN 32 > +#define MCE_LOG_LEN 128 > #define MCE_LOG_SIGNATURE "MACHINECHECK" Hmm, I don't think this is what I meant when we talked about it previously. So let me try again: Now that we have this shiny 2-pages sized lockless gen_pool, why are we still dealing with struct mce_log mcelog? Why can't we rip it out and kill it finally? And switch to the gen_pool? All code that reads from mcelog - /dev/mcelog chrdev - should switch to the lockless buffer and will iterate through the logged MCEs there. I think this way we're much better prepared for future machine sizes. We can even use memblock to allocate appropriate memory at boot for the gen_pool if the 2 pages are not enough. Hmmm? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.