archive mirror
 help / color / mirror / Atom feed
From: Usama Arif <>
To: David Woodhouse <>,,
Subject: Re: [PATCH 0/9] Parallel CPU bringup for x86_64
Date: Thu, 2 Feb 2023 21:59:29 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 02/02/2023 10:02, David Woodhouse wrote:
> On Wed, 2023-02-01 at 20:43 +0000, Usama Arif wrote:
>> This patchseries is from the work done by David Woodhouse (v4:
>> The parallel CPU bringup is disabled for all AMD CPUs in this version: (see discussions: and
>> Doing INIT/SIPI/SIPI in parallel brings down the time for smpboot from ~700ms
>> to 100ms (85% improvement) on a server with 128 CPUs split across 2 NUMA
>> nodes.
>> Adding another cpuhp state for do_wait_cpu_initialized to make sure cpu_init
>> is reached in parallel as proposed by David in v1 will bring it down further
>> to ~30ms. Making this change would be dependent on this patchseries, so they
>> could be explored if this gets merged.
>> Changes across versions:
>> v2: Cut it back to just INIT/SIPI/SIPI in parallel for now, nothing more
>> v3: Clean up x2apic patch, add MTRR optimisation, lock topology update
>>      in preparation for more parallelisation.
>> v4: Fixes to the real mode parallelisation patch spotted by SeanC, to
>>      avoid scribbling on initial_gs in common_cpu_up(), and to allow all
>>      24 bits of the physical X2APIC ID to be used. That patch still needs
>>      a Signed-off-by from its original author, who once claimed not to
>>      remember writing it at all. But now we've fixed it, hopefully he'll
>>      admit it now :)
>> v5: rebase to v6.1 and remeasure performance, disable parallel bringup
>>      for AMD CPUs.
> Thanks, Usama.
> I've updated to v6.2-rc6 since there were a few more tweaks required
> (and we should double-check that the new handling of cache_ap_init from
> a dedicated cpuhp step works right if that ends up being done in
> parallel).
> I also fixed up the complaints from the test robot; including
> <linux/smpboot.h> from smpboot.c and making do_cpu_up() static, and
> putting #ifdef CONFIG_SMP around the 'are we booting the AP?' check and
> code segment in head_64.S.
> I've made the AMD thing a CPU bug as Peter suggested, and pushed it to
> for you to do the real work of actually testing it :)

Thanks David! I have tested and reposted the v6.2-rc6 patches. One thing 
I was mistaken about since I had rebased the patches together was that 
the last 100ms to 30ms optimization was coming from parallelization in 
x86/cpu:wait-init, when it seems to have a negligible affect. The last 
70ms optimization was coming mainly from reusing timer calibration. Its 
a simple patch and I have added it at the end of the series. The only 
thing thats' missing was a sign-off from the author who I have added to 
the latest series.

      reply	other threads:[~2023-02-02 22:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 20:43 [PATCH 0/9] Parallel CPU bringup for x86_64 Usama Arif
2023-02-01 20:43 ` [PATCH 1/9] x86/apic/x2apic: Fix parallel handling of cluster_mask Usama Arif
2023-02-01 20:43 ` [PATCH 2/9] cpu/hotplug: Move idle_thread_get() to <linux/smpboot.h> Usama Arif
2023-02-01 20:43 ` [PATCH 3/9] cpu/hotplug: Add dynamic parallel bringup states before CPUHP_BRINGUP_CPU Usama Arif
2023-02-01 20:43 ` [PATCH 4/9] x86/smpboot: Reference count on smpboot_setup_warm_reset_vector() Usama Arif
2023-02-01 20:43 ` [PATCH 5/9] x86/smpboot: Split up native_cpu_up into separate phases and document them Usama Arif
2023-02-01 20:43 ` [PATCH 6/9] x86/smpboot: Support parallel startup of secondary CPUs Usama Arif
2023-02-01 20:43 ` [PATCH 7/9] x86/smpboot: Send INIT/SIPI/SIPI to secondary CPUs in parallel Usama Arif
2023-02-01 20:43 ` [PATCH 8/9] x86/mtrr: Avoid repeated save of MTRRs on boot-time CPU bringup Usama Arif
2023-02-01 20:43 ` [PATCH 9/9] x86/smpboot: Serialize topology updates for secondary bringup Usama Arif
2023-02-02 10:02 ` [PATCH 0/9] Parallel CPU bringup for x86_64 David Woodhouse
2023-02-02 21:59   ` Usama Arif [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).