From: Borislav Petkov <bp@alien8.de>
To: Ashok Raj <ashok.raj@intel.com>
Cc: linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
Tony Luck <tony.luck@intel.com>
Subject: Re: [Patch V1 1/3] x86, mce: MCE log size not enough for high core parts
Date: Thu, 24 Sep 2015 17:47:22 +0200 [thread overview]
Message-ID: <20150924154722.GD3774@pd.tnic> (raw)
In-Reply-To: <1443073720-3940-1-git-send-email-ashok.raj@intel.com>
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 <ashok.raj@intel.com>
> Suggested-by: Tony Luck <tony.luck@intel.com>
> ---
> 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.
next prev parent reply other threads:[~2015-09-24 15:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-24 5:48 [Patch V1 1/3] x86, mce: MCE log size not enough for high core parts Ashok Raj
2015-09-24 5:48 ` [Patch V1 2/3] x86, mce: Refactor parts of mce_log() to reuse when logging from offline CPUs Ashok Raj
2015-09-24 5:48 ` [Patch V1 3/3] x86, mce: Account for offline CPUs during MCE rendezvous Ashok Raj
2015-09-24 15:47 ` Borislav Petkov [this message]
2015-09-24 18:44 ` [Patch V1 1/3] x86, mce: MCE log size not enough for high core parts Luck, Tony
2015-09-24 18:52 ` Borislav Petkov
2015-09-24 19:00 ` Luck, Tony
2015-09-24 19:22 ` Borislav Petkov
2015-09-24 20:22 ` Raj, Ashok
2015-09-24 21:07 ` Borislav Petkov
2015-09-24 21:25 ` Raj, Ashok
2015-09-25 8:29 ` Borislav Petkov
2015-09-25 16:29 ` Raj, Ashok
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150924154722.GD3774@pd.tnic \
--to=bp@alien8.de \
--cc=ashok.raj@intel.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.