From: David Woodhouse <dwmw2@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>,
Usama Arif <usama.arif@bytedance.com>,
kim.phillips@amd.com, brgerst@gmail.com
Cc: piotrgorski@cachyos.org, oleksandr@natalenko.name,
arjan@linux.intel.com, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org,
pbonzini@redhat.com, paulmck@kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
rcu@vger.kernel.org, mimoja@mimoja.de, hewenliang4@huawei.com,
thomas.lendacky@amd.com, seanjc@google.com,
pmenzel@molgen.mpg.de, fam.zheng@bytedance.com,
punit.agrawal@bytedance.com, simon.evans@bytedance.com,
liangma@liangbit.com, gpiccoli@igalia.com
Subject: Re: [PATCH v16 3/8] cpu/hotplug: Add dynamic parallel bringup states before CPUHP_BRINGUP_CPU
Date: Fri, 24 Mar 2023 15:33:17 +0000 [thread overview]
Message-ID: <f363eb51084bcaa2adb383568965b23d573e91b1.camel@infradead.org> (raw)
In-Reply-To: <87pm8y6yme.ffs@tglx>
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
On Fri, 2023-03-24 at 14:57 +0100, Thomas Gleixner wrote:
>
> Why? Simply because of this:
>
> BP AP state
> kick() BRINGUP_CPU
> startup()
> sync() sync()
> starting() advances to AP_ONLINE
> sync() sync()
> TSC_sync() TSC_sync()
> wait_for_online() set_online()
> cpu_startup_entry() AP_ONLINE_IDLE
> wait_for_completion() complete()
>
> This works correctly today because bringup_cpu() does not modify state
> and excpects the state to be advanced by the AP once the completion is
> done.
>
> So you _cannot_ just throw some magic dynamic states before BRINGUP_CPU
> and then expect that the state machine is consistent when the AP is
> allowed to run the starting callbacks in parallel.
Aha! I see.
Yes, when the AP calls notify_cpu_starting(), which x86 does from
smp_callin(), the AP takes *itself* forward through the states from
there.
That happens when the BP gets to do_wait_cpu_initialized(). So yes, the
actual code in the existing series of patches is entirely safe, but
you're right that we do only want that *one* additional state for
parallelising the "kick AP" before CPUHP_BRINGUP_CPU. The rest need to
come afterwards and be handled differently.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]
next prev parent reply other threads:[~2023-03-24 15:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-21 19:40 [PATCH v16 0/8] Parallel CPU bringup for x86_64 Usama Arif
2023-03-21 19:40 ` [PATCH v16 1/8] cpu/hotplug: Move idle_thread_get() to <linux/smpboot.h> Usama Arif
2023-03-21 19:40 ` [PATCH v16 2/8] cpu/hotplug: Reset task stack state in _cpu_up() Usama Arif
2023-03-22 11:06 ` Mark Rutland
2023-03-21 19:40 ` [PATCH v16 3/8] cpu/hotplug: Add dynamic parallel bringup states before CPUHP_BRINGUP_CPU Usama Arif
2023-03-23 22:36 ` Thomas Gleixner
2023-03-23 22:49 ` David Woodhouse
2023-03-23 23:48 ` Thomas Gleixner
2023-03-24 0:06 ` David Woodhouse
2023-03-23 23:05 ` Thomas Gleixner
2023-03-23 23:12 ` David Woodhouse
2023-03-24 1:16 ` Thomas Gleixner
2023-03-24 9:31 ` David Woodhouse
2023-03-24 13:57 ` Thomas Gleixner
2023-03-24 15:33 ` David Woodhouse [this message]
2023-03-24 14:07 ` Thomas Gleixner
2023-03-24 9:46 ` Thomas Gleixner
2023-03-24 10:00 ` David Woodhouse
2023-03-27 18:48 ` David Woodhouse
2023-03-21 19:40 ` [PATCH v16 4/8] x86/smpboot: Split up native_cpu_up into separate phases and document them Usama Arif
2023-03-21 19:40 ` [PATCH v16 5/8] x86/smpboot: Support parallel startup of secondary CPUs Usama Arif
2023-03-21 19:40 ` [PATCH v16 6/8] x86/smpboot: Send INIT/SIPI/SIPI to secondary CPUs in parallel Usama Arif
2023-03-21 19:40 ` [PATCH v16 7/8] x86/smpboot: Serialize topology updates for secondary bringup Usama Arif
2023-03-21 19:40 ` [PATCH v16 8/8] x86/smpboot: Allow parallel bringup for SEV-ES Usama Arif
2023-03-22 22:47 ` Borislav Petkov
2023-03-23 8:32 ` David Woodhouse
2023-03-23 8:51 ` Borislav Petkov
2023-03-23 9:04 ` David Woodhouse
2023-03-23 14:23 ` Brian Gerst
2023-03-27 17:47 ` Borislav Petkov
2023-03-27 18:14 ` David Woodhouse
2023-03-27 19:14 ` Tom Lendacky
2023-03-27 19:32 ` Borislav Petkov
2023-03-23 13:16 ` Tom Lendacky
[not found] ` <751f572f940220775054dc09324b20b929d7d66d.camel@amazon.co.uk>
2023-03-23 18:28 ` Tom Lendacky
2023-03-23 22:13 ` Borislav Petkov
2023-03-23 22:30 ` [EXTERNAL][PATCH " David Woodhouse
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=f363eb51084bcaa2adb383568965b23d573e91b1.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=fam.zheng@bytedance.com \
--cc=gpiccoli@igalia.com \
--cc=hewenliang4@huawei.com \
--cc=hpa@zytor.com \
--cc=kim.phillips@amd.com \
--cc=kvm@vger.kernel.org \
--cc=liangma@liangbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mimoja@mimoja.de \
--cc=mingo@redhat.com \
--cc=oleksandr@natalenko.name \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=piotrgorski@cachyos.org \
--cc=pmenzel@molgen.mpg.de \
--cc=punit.agrawal@bytedance.com \
--cc=rcu@vger.kernel.org \
--cc=seanjc@google.com \
--cc=simon.evans@bytedance.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=usama.arif@bytedance.com \
--cc=x86@kernel.org \
/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.