From: Henrique de Moraes Holschuh <email@example.com> To: Borislav Petkov <firstname.lastname@example.org> Cc: X86 ML <email@example.com>, Arjan Van De Ven <firstname.lastname@example.org>, Ashok Raj <email@example.com>, Tom Lendacky <firstname.lastname@example.org>, LKML <email@example.com> Subject: Re: [PATCH 7/7] x86/microcode: Synchronize late microcode loading Date: Wed, 28 Feb 2018 14:48:48 -0300 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20180228140806.GD3769@pd.tnic> On Wed, 28 Feb 2018, Borislav Petkov wrote: > On Wed, Feb 28, 2018 at 10:59:31AM -0300, Henrique de Moraes Holschuh wrote: > > Eek! If I read that right, this effectively halts the entire box until > > every core is updated, with one core entering deep-coma at a time (the > > rest are left either spinning or cpu_relax()ing > > I think *you* should relax. :) Well, I don't expect any general-use distro to unleash late loading on the users, certainly :-) Least of all, Debian... It is, nowadays, "use it only if you know what you're doing" land. But it is not yet sufficiently documented as such, I fear. > Late microcode loading on a long running box is not something you do > more than 2-3 times a year. And if the box needs to restart, it'll get > the early microcode. Sure, but the thing is so damn expensive (and the time it takes is directly proportional to the number of cores, thus likely to hurt worse exactly those who would want to use it), that I was left wondering if it should not be optimized further to do the work in parallel (if that can be made safe enough). Besides, we likely don't want to have early microcode updates end up being the reason AP bringup has to be serialized during boot either (and it *is* likely to dominate the time taken for AP bringup, too!), so it would be nice to have a way to make parallel microcode updates possible in general... but I don't think we're there, yet. No matter. I am not opposing the patch in the first place. And any paralell microcode update work would be best done in an incremental fashion, on top of working serial updates, anyway. > And yes, this is addressing *late* loading, if you haven't noticed yet. I did get that message, yes :) > So keep doing the early method and you'll be fine. We need that in the documentation :-P Microcode updates have always been somewhat slow, but now they are potentially going to be *much* more painful and noticeable in the late-update case... -- Henrique Holschuh
next prev parent reply other threads:[~2018-02-28 17:48 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-28 10:28 [PATCH 0/7] x86/microcode: Improve late loading Borislav Petkov 2018-02-28 10:28 ` [PATCH 1/7] x86/microcode: Get rid of struct apply_microcode_ctx Borislav Petkov 2018-03-08 9:25 ` [tip:x86/pti] " tip-bot for Borislav Petkov 2018-02-28 10:28 ` [PATCH 2/7] x86/microcode/intel: Check microcode revision before updating sibling threads Borislav Petkov 2018-03-08 9:25 ` [tip:x86/pti] " tip-bot for Ashok Raj 2018-02-28 10:28 ` [PATCH 3/7] x86/microcode/intel: Writeback and invalidate caches before updating microcode Borislav Petkov 2018-03-08 9:26 ` [tip:x86/pti] " tip-bot for Ashok Raj 2018-02-28 10:28 ` [PATCH 4/7] x86/microcode: Do not upload microcode if CPUs are offline Borislav Petkov 2018-02-28 13:11 ` Henrique de Moraes Holschuh 2018-02-28 13:26 ` Raj, Ashok 2018-02-28 19:07 ` Henrique de Moraes Holschuh 2018-03-05 22:06 ` Tom Lendacky 2018-03-08 9:26 ` [tip:x86/pti] " tip-bot for Ashok Raj 2018-02-28 10:28 ` [PATCH 5/7] x86/microcode/intel: Look into the patch cache first Borislav Petkov 2018-03-08 9:27 ` [tip:x86/pti] " tip-bot for Borislav Petkov 2018-02-28 10:28 ` [PATCH 6/7] x86/microcode: Request microcode on the BSP Borislav Petkov 2018-03-05 22:08 ` Tom Lendacky 2018-03-08 9:27 ` [tip:x86/pti] " tip-bot for Borislav Petkov 2018-02-28 10:28 ` [PATCH 7/7] x86/microcode: Synchronize late microcode loading Borislav Petkov 2018-02-28 13:59 ` Henrique de Moraes Holschuh 2018-02-28 14:08 ` Borislav Petkov 2018-02-28 17:48 ` Henrique de Moraes Holschuh [this message] 2018-03-05 22:09 ` Tom Lendacky 2018-03-08 9:28 ` [tip:x86/pti] " tip-bot for Ashok Raj 2018-03-05 22:12 ` [PATCH 0/7] x86/microcode: Improve late loading Tom Lendacky 2018-03-05 23:51 ` 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 7/7] x86/microcode: Synchronize late microcode loading' \ /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
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.