[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch v3 08/36] x86/smpboot: Split up native_cpu_up() into separate phases and document them
- To: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- Date: Wed, 10 May 2023 10:39:24 +0200
- Cc: LKML <linux-kernel@xxxxxxxxxxxxxxx>, x86@xxxxxxxxxx, David Woodhouse <dwmw2@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Brian Gerst <brgerst@xxxxxxxxx>, Arjan van de Veen <arjan@xxxxxxxxxxxxxxx>, Paolo Bonzini <pbonzini@xxxxxxxxxx>, Paul McKenney <paulmck@xxxxxxxxxx>, Tom Lendacky <thomas.lendacky@xxxxxxx>, Sean Christopherson <seanjc@xxxxxxxxxx>, Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx>, Paul Menzel <pmenzel@xxxxxxxxxxxxx>, "Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxx>, Piotr Gorski <lucjan.lucjanov@xxxxxxxxx>, Usama Arif <usama.arif@xxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Russell King <linux@xxxxxxxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, Catalin Marinas <catalin.marinas@xxxxxxx>, Will Deacon <will@xxxxxxxxxx>, Guo Ren <guoren@xxxxxxxxxx>, linux-csky@xxxxxxxxxxxxxxx, Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>, linux-mips@xxxxxxxxxxxxxxx, "James E.J. Bottomley" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>, Helge Deller <deller@xxxxxx>, linux-parisc@xxxxxxxxxxxxxxx, Paul Walmsley <paul.walmsley@xxxxxxxxxx>, Palmer Dabbelt <palmer@xxxxxxxxxxx>, linux-riscv@xxxxxxxxxxxxxxxxxxx, Mark Rutland <mark.rutland@xxxxxxx>, Sabin Rapan <sabrapan@xxxxxxxxxx>, "Michael Kelley (LINUX)" <mikelley@xxxxxxxxxxxxx>, David Woodhouse <dwmw@xxxxxxxxxxxx>
- Delivery-date: Wed, 10 May 2023 08:41:08 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, May 09, 2023 at 10:11:05PM +0200, Thomas Gleixner wrote:
> On Tue, May 09 2023 at 12:04, Peter Zijlstra wrote:
> > On Mon, May 08, 2023 at 09:43:39PM +0200, Thomas Gleixner wrote:
> > Not to the detriment of this patch, but this barrier() and it's comment
> > seem weird vs smp_callin(). That function ends with an atomic bitop (it
> > has to, at the very least it must not be weaker than store-release) but
> > also has an explicit wmb() to order setup vs CPU_STARTING.
> >
> > (arguably that should be a full fence *AND* get a comment)
>
> TBH: I'm grasping for something 'arguable': What's the point of this
> wmb() or even a mb()?
>
> Most of the [w]mb()'s in smpboot.c except those in mwait_play_dead()
> have a very distinct voodoo programming smell.
Oh fully agreed, esp. without a comment these things are hugely suspect.
I could not immediately see purpose either.
My arguably argument was about IF it was needed at all, then it would
make more sense to me to also constrain loads. But I'd be more than
happy to see the whole thing go. But perhaps not in this series?
|
