All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Koralahalli Channabasappa, Smita" <skoralah@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
	x86@kernel.org, linux-edac@vger.kernel.org,
	linux-kernel@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	James Morse <james.morse@arm.com>,
	Robert Richter <rric@kernel.org>,
	Yazen Ghannam <yazen.ghannam@amd.com>
Subject: Re: [PATCH v3 3/4] x86/mce, EDAC/mce_amd: Cache MCA_CONFIG[McaX] in struct mce_bank
Date: Wed, 23 Feb 2022 16:25:07 -0600	[thread overview]
Message-ID: <340dc083-683a-0f4b-0c58-62e86820a593@amd.com> (raw)
In-Reply-To: <YhVSecR7DqhNvFod@zn.tnic>

On 2/22/22 3:15 PM, Borislav Petkov wrote:
> On Tue, Feb 22, 2022 at 02:47:44PM -0600, Koralahalli Channabasappa, Smita wrote:
>> But what do you think of severity? Will this make an impact when handling
>> panic severity levels? .. mce_severity_amd_smca().
> Well, look at the code: severity grading gets called when either polling
> or #MC handler gets to log an MCE. Reading an MSR costs a couple of
> hundred cycles. The whole MCE logging path costs maybe a couple of
> *orders* of magnitude more so that MSR read is in the noise when you
> have a 4GHz CPU executing 4 billion cycles per second.
>
> Now, that's for a single MCE.
>
> If it were more, say 10s, 100s, 1000s MCEs, then the MSR read is the
> least of your problems.
>
> But this is me conjecturing - I'm always interested in a real proof
> where it shows or it does not.
>
> I guess what I'm trying to say is, yeah, sure, speed is mostly a good
> argument. But you always need to consider at what cost you'd get that
> speed. And if at all. There are other important things like keeping the
> code base maintainable, readable and able to accept modifications for
> new features.
>
> So there's always this question of balance that needs to be asked...
>
Okay, this makes sense to me now. Thanks for the explanation. I will
drop this patch in the next series.

Thanks,
Smita


  reply	other threads:[~2022-02-23 22:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-11 22:34 [PATCH v3 0/4] x86/mce, EDAC/mce_amd: Support extended MCA_ADDR address on SMCA systems Smita Koralahalli
2022-02-11 22:34 ` [PATCH v3 1/4] x86/mce: Define function to extract ErrorAddr from MCA_ADDR Smita Koralahalli
2022-02-22 15:35   ` Borislav Petkov
2022-02-22 20:34     ` Koralahalli Channabasappa, Smita
2022-02-11 22:34 ` [PATCH v3 2/4] x86/mce: Add support for Extended Physical Address MCA changes Smita Koralahalli
2022-02-11 22:34 ` [PATCH v3 3/4] x86/mce, EDAC/mce_amd: Cache MCA_CONFIG[McaX] in struct mce_bank Smita Koralahalli
2022-02-22 15:35   ` Borislav Petkov
2022-02-22 20:47     ` Koralahalli Channabasappa, Smita
2022-02-22 21:15       ` Borislav Petkov
2022-02-23 22:25         ` Koralahalli Channabasappa, Smita [this message]
2022-02-11 22:34 ` [PATCH v3 4/4] x86/mce: Avoid unnecessary padding " Smita Koralahalli
2022-02-22 15:36   ` Borislav Petkov
2022-02-22 21:02     ` Koralahalli Channabasappa, Smita

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=340dc083-683a-0f4b-0c58-62e86820a593@amd.com \
    --to=skoralah@amd.com \
    --cc=Smita.KoralahalliChannabasappa@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rric@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yazen.ghannam@amd.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.