All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mihai Carabas <mihai.carabas@oracle.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org, bp@alien8.de, ashok.raj@intel.com,
	boris.ostrovsky@oracle.com, konrad.wilk@oracle.com,
	patrick.colp@oracle.com, kanth.ghatraju@oracle.com,
	Jon.Grimm@amd.com, Thomas.Lendacky@amd.com
Subject: Re: [PATCH] Parallel microcode update in Linux
Date: Mon, 2 Sep 2019 14:10:33 +0300	[thread overview]
Message-ID: <c2bafc82-2e93-ab5c-d1ac-68ef94d8eebc@oracle.com> (raw)
In-Reply-To: <20190902073931.GA15850@amd>

La 02.09.2019 10:39, Pavel Machek a scris:
> Hi!
> 
>>>> +       u64 p0, p1;
>>>>         int ret;
>>>>
>>>>         atomic_set(&late_cpus_in,  0);
>>>>         atomic_set(&late_cpus_out, 0);
>>>>
>>>> +       p0 = rdtsc_ordered();
>>>> +
>>>>         ret = stop_machine_cpuslocked(__reload_late, NULL, cpu_online_mask);
>>>> +
>>>> +       p1 = rdtsc_ordered();
>>>> +
>>>>         if (ret > 0)
>>>>                 microcode_check();
>>>>
>>>>         pr_info("Reload completed, microcode revision: 0x%x\n", boot_cpu_data.microcode);
>>>>
>>>> +       pr_info("p0: %lld, p1: %lld, diff: %lld\n", p0, p1, p1 - p0);
>>>> +
>>>>         return ret;
>>>> }
>>>>
>>>> We have used a machine with a broken microcode in BIOS and no microcode in
>>>> initramfs (to bypass early loading).
>>>>
>>>> Here are the results for parallel loading (we made two measurements):
>>>
>>>> [   18.197760] microcode: updated to revision 0x200005e, date = 2019-04-02
>>>> [   18.201225] x86/CPU: CPU features have changed after loading microcode, but might not take effect.
>>>> [   18.201230] microcode: Reload completed, microcode revision: 0x200005e
>>>> [   18.201232] microcode: p0: 118138123843052, p1: 118138153732656, diff: 29889604
>>>
>>>> Here are the results of serial loading:
>>>>
>>>> [   17.542518] microcode: updated to revision 0x200005e, date = 2019-04-02
>>>> [   17.898365] x86/CPU: CPU features have changed after loading microcode, but might not take effect.
>>>> [   17.898370] microcode: Reload completed, microcode revision: 0x200005e
>>>> [   17.898372] microcode: p0: 149220216047388, p1: 149221058945422, diff: 842898034
>>>>
>>>> One can see that the difference is an order magnitude.
>>>
>>> Well, that's impressive, but it seems to finish 300 msec later? Where does that difference
>>> come from / how much real time do you gain by this?
>>
>> The difference comes from the large amount of cores/threads the machine has: 72 in this case, but there are machines with more. As the commit message says initially the microcode was applied serially one by one and now the microcode is updated in parallel on all cores.
>>
>> 300ms seems nothing but it is enough to cause disruption in some critical services (e.g. storage) - 300ms in which we do not execute anything on CPUs. Also this 300ms is increasing when the machine is fully loaded with guests.
>>
> 
> Yes, but if you look at the dmesgs I quoted, paralel microcode update
> actually finished 300msec _later_.

That is the serial loading (it is written before: "Here are the results 
of serial loading:"), parallel is before. Am I missing something?


> 									Pavel
> 


      reply	other threads:[~2019-09-02 11:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-22 20:43 [PATCH] Parallel microcode update in Linux Mihai Carabas
2019-08-22 20:43 ` [PATCH] x86/microcode: Update microcode for all cores in parallel Mihai Carabas
2019-08-24  8:51   ` Borislav Petkov
2019-08-24  8:53     ` [PATCH 1/2] x86/microcode: Update late microcode " Borislav Petkov
2019-08-26 12:53       ` Boris Ostrovsky
2019-08-26 13:03         ` Borislav Petkov
2019-08-26 20:32         ` Raj, Ashok
2019-08-27 19:43           ` Boris Ostrovsky
2019-08-27 21:24             ` Boris Ostrovsky
2019-08-28 19:16               ` Borislav Petkov
2019-08-26 20:23       ` Raj, Ashok
2019-08-27 12:25         ` Borislav Petkov
2019-08-28  0:56           ` Raj, Ashok
2019-08-28 19:13             ` Borislav Petkov
2019-08-28 19:45               ` Raj, Ashok
2019-08-24  8:53     ` [PATCH 2/2] x86/microcode/intel: Issue the revision updated message only on the BSP Borislav Petkov
2019-08-26 13:34       ` Boris Ostrovsky
2019-08-26 13:45         ` Borislav Petkov
2019-10-01 17:43       ` [tip: x86/microcode] " tip-bot2 for Borislav Petkov
2019-10-01 17:43   ` [tip: x86/microcode] x86/microcode: Update late microcode in parallel tip-bot2 for Ashok Raj
2019-09-01 17:25 ` [PATCH] Parallel microcode update in Linux Pavel Machek
2019-09-02  7:27   ` Mihai Carabas
2019-09-02  7:39     ` Pavel Machek
2019-09-02 11:10       ` Mihai Carabas [this message]

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=c2bafc82-2e93-ab5c-d1ac-68ef94d8eebc@oracle.com \
    --to=mihai.carabas@oracle.com \
    --cc=Jon.Grimm@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=ashok.raj@intel.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=kanth.ghatraju@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patrick.colp@oracle.com \
    --cc=pavel@ucw.cz \
    /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.