Messages in this thread | | | Subject | Re: [PATCH v3 3/4] x86/mce, EDAC/mce_amd: Cache MCA_CONFIG[McaX] in struct mce_bank | From | "Koralahalli Channabasappa, Smita" <> | Date | Wed, 23 Feb 2022 16:25:07 -0600 |
| |
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
| |