From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Patryk Wlazlyn <patryk.wlazlyn@linux.intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, rafael.j.wysocki@intel.com,
len.brown@intel.com, dave.hansen@linux.intel.com
Subject: Re: [PATCH v3 2/3] x86/smp native_play_dead: Prefer cpuidle_play_dead() over mwait_play_dead()
Date: Fri, 15 Nov 2024 02:21:19 +0100 [thread overview]
Message-ID: <871pzd1ecw.ffs@tglx> (raw)
In-Reply-To: <20241114120315.GG38972@noisy.programming.kicks-ass.net>
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
next prev parent reply other threads:[~2024-11-15 1:21 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 12:29 [PATCH v3 0/3] SRF: Fix offline CPU preventing pc6 entry Patryk Wlazlyn
2024-11-08 12:29 ` [PATCH v3 1/3] x86/smp: Allow calling mwait_play_dead with arbitrary hint Patryk Wlazlyn
2024-11-08 16:03 ` Dave Hansen
2024-11-12 10:54 ` Patryk Wlazlyn
2024-11-08 12:29 ` [PATCH v3 2/3] x86/smp native_play_dead: Prefer cpuidle_play_dead() over mwait_play_dead() Patryk Wlazlyn
2024-11-08 16:14 ` Dave Hansen
2024-11-12 10:55 ` Patryk Wlazlyn
2024-11-12 11:47 ` Peter Zijlstra
2024-11-12 12:03 ` Rafael J. Wysocki
2024-11-12 12:18 ` Peter Zijlstra
2024-11-12 12:30 ` Rafael J. Wysocki
2024-11-12 12:38 ` Rafael J. Wysocki
2024-11-12 13:49 ` Peter Zijlstra
2024-11-12 14:56 ` Rafael J. Wysocki
2024-11-12 15:08 ` Peter Zijlstra
2024-11-12 16:24 ` Rafael J. Wysocki
2024-11-12 12:44 ` Artem Bityutskiy
2024-11-12 14:01 ` Peter Zijlstra
2024-11-14 12:03 ` Peter Zijlstra
2024-11-15 1:21 ` Thomas Gleixner [this message]
2024-11-15 10:07 ` Peter Zijlstra
2024-11-15 15:37 ` Thomas Gleixner
2024-11-12 13:23 ` Rafael J. Wysocki
2024-11-12 14:56 ` Peter Zijlstra
2024-11-12 15:00 ` Rafael J. Wysocki
2024-11-13 11:41 ` Gautham R. Shenoy
2024-11-13 16:14 ` Dave Hansen
2024-11-14 5:06 ` Gautham R. Shenoy
2024-11-13 16:22 ` Peter Zijlstra
2024-11-13 16:27 ` Wysocki, Rafael J
2024-11-14 11:58 ` Rafael J. Wysocki
2024-11-14 12:17 ` Peter Zijlstra
2024-11-14 17:36 ` Gautham R. Shenoy
2024-11-14 17:58 ` Rafael J. Wysocki
2024-11-14 11:58 ` Peter Zijlstra
2024-11-14 17:24 ` Gautham R. Shenoy
2024-11-15 10:11 ` Peter Zijlstra
2024-11-25 5:45 ` Gautham R. Shenoy
2024-11-08 12:29 ` [PATCH v3 3/3] intel_idle: Provide enter_dead() handler for SRF Patryk Wlazlyn
2024-11-08 16:21 ` Dave Hansen
2024-11-12 10:57 ` Patryk Wlazlyn
2024-11-12 11:28 ` Rafael J. Wysocki
2024-11-12 16:07 ` Dave Hansen
2024-11-12 19:17 ` Thomas Gleixner
2024-11-12 19:43 ` Rafael J. Wysocki
2024-11-08 22:12 ` kernel test robot
2024-11-08 16:22 ` [PATCH v3 0/3] SRF: Fix offline CPU preventing pc6 entry Dave Hansen
2024-11-12 11:45 ` Peter Zijlstra
2024-11-12 15:43 ` Patryk Wlazlyn
2024-11-13 1:19 ` Thomas Gleixner
2024-11-14 17:13 ` Patryk Wlazlyn
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=871pzd1ecw.ffs@tglx \
--to=tglx@linutronix.de \
--cc=artem.bityutskiy@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=patryk.wlazlyn@linux.intel.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--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 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).