On 13 February 2023 23:30:20 CET, Usama Arif <usama.arif@xxxxxxxxxxxxx> wrote: > > >On 13/02/2023 20:53, David Woodhouse wrote: >> >> >> On 13 February 2023 21:43:13 CET, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: >>> On Thu, Feb 09 2023 at 15:41, Usama Arif wrote: >>>> From: David Woodhouse <dwmw@xxxxxxxxxxxx> >>>> >>>> The toplogy update is performed by the AP via smp_callin() after the BSP >>>> has called do_wait_cpu_initialized(), setting the AP's bit in >>>> cpu_callout_mask to allow it to proceed. >>>> >>>> In preparation to enable further parallelism of AP bringup, add locking to >>>> serialize the update even if multiple APs are (in future) permitted to >>>> proceed through the next stages of bringup in parallel. >>> >>> This one is also only relevant for further parallelisation, right? >> >> I believe so, yes. But it's low-hanging fruit and might as well go in now. > >Yes, only needed if we parallelize further, i.e. after do_wait_cpu_initialized. As David said, its a simple enough and easy patch, but its not needed for parallelizing INIT/SIPI. > >I tested Davids' part2 branch (https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/parallel-6.2-rc7) again just to be sure, and the only commit that makes a significant difference in smpboot time on top of part1 (this series) is reusing timer calibration (100ms to 34ms). > >Parallelizing do_wait_cpu_initialized didn't significantly improve smpboot time (only reduced to 31ms on average of 4 runs so maybe within the margin of error?), so I think its better to move this patch into its own series with any further parallelization only if it shows a further improvement in smpboot time? Let's do it anyway; it's harmless to make it thread-safe even if it doesn't get invoked that way today. There is further parallelism to be had with letting the APs run themselves all the way to the online state, and the "part2" in my tree is only the next step towards that.
