[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871pzd1ecw.ffs@tglx>
Date: Fri, 15 Nov 2024 02:21:19 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>, Artem Bityutskiy
<artem.bityutskiy@...ux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Patryk Wlazlyn
<patryk.wlazlyn@...ux.intel.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
rafael.j.wysocki@...el.com, len.brown@...el.com,
dave.hansen@...ux.intel.com
Subject: Re: [PATCH v3 2/3] x86/smp native_play_dead: Prefer
cpuidle_play_dead() over mwait_play_dead()
On Thu, Nov 14 2024 at 13:03, Peter Zijlstra wrote:
> On Tue, Nov 12, 2024 at 03:01:27PM +0100, Peter Zijlstra wrote:
>
>> No, not mwait hint. We need an instruction that:
>>
>> - goes to deepest C state
>> - drops into WAIT-for-Start-IPI (SIPI)
>>
>> Notably, it should not wake from:
>>
>> - random memory writes
>> - NMI, MCE, SMI and other such non-maskable thingies
>> - anything else -- the memory pointed to by RIP might no longer exist
>>
>> Lets call the instruction: DEAD.
>
> So, turns out that when you send INIT to an AP it does the whole drop
> into Wait-for-SIPI and ignore non-maskable crap.
>
> The reason we don't do that is because INIT to CPU0 (BP) is somewhat
> fatal, but since Thomas killed all that CPU0 hotplug crap, I think we
> can actually go do that.
Instead of playing dead or to kick out CPUs from whatever dead play
routine they are in?
playimg dead is to stay because INIT will bring back the MCE broadcast
problem, which we try to avoid by bringing SMT siblings up just to shut
them down again by playing dead.
You need a MCE broadcast free system and/or some sensible BIOS bringup
code for that to work...
Thanks,
tglx
Powered by blists - more mailing lists