linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sohil Mehta <sohil.mehta@intel.com>
To: x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>,
	Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>, Andy Lutomirski <luto@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Jean Delvare <jdelvare@suse.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Zhang Rui <rui.zhang@intel.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	David Laight <david.laight.linux@gmail.com>,
	Dapeng Mi <dapeng1.mi@linux.intel.com>,
	Sohil Mehta <sohil.mehta@intel.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org
Subject: [PATCH v3 09/15] x86/smpboot: Remove confusing quirk usage in INIT delay
Date: Wed, 19 Feb 2025 18:41:27 +0000	[thread overview]
Message-ID: <20250219184133.816753-10-sohil.mehta@intel.com> (raw)
In-Reply-To: <20250219184133.816753-1-sohil.mehta@intel.com>

Very old multiprocessor systems required a 10 msec delay between
asserting and de-asserting INIT but modern processors do not require
this delay.

Over time the usage of the "quirk" wording while setting the INIT delay
has become misleading. The code comments suggest that modern processors
need to be quirked, which clears the default init_udelay of 10 msec,
while legacy processors don't need the quirk and continue to use the
default init_udelay.

With a lot more modern processors, the wording should be inverted if at
all needed. Instead, simplify the comments and the code by getting rid
of "quirk" usage altogether and clarifying the following:

Old legacy processors -> Set the "legacy" 10 msec delay
Modern processors     -> Do not set any delay

No functional change.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v3: Improve commit message
v2: New patch
---
 arch/x86/kernel/smpboot.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index c10850ae6f09..eb91ed0f2a06 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -654,10 +654,9 @@ static void impress_friends(void)
  * But that slows boot and resume on modern processors, which include
  * many cores and don't require that delay.
  *
- * Cmdline "init_cpu_udelay=" is available to over-ride this delay.
- * Modern processor families are quirked to remove the delay entirely.
+ * Cmdline "cpu_init_udelay=" is available to override this delay.
  */
-#define UDELAY_10MS_DEFAULT 10000
+#define UDELAY_10MS_LEGACY 10000
 
 static unsigned int init_udelay = UINT_MAX;
 
@@ -669,7 +668,7 @@ static int __init cpu_init_udelay(char *str)
 }
 early_param("cpu_init_udelay", cpu_init_udelay);
 
-static void __init smp_quirk_init_udelay(void)
+static void __init smp_set_init_udelay(void)
 {
 	/* if cmdline changed it from default, leave it alone */
 	if (init_udelay != UINT_MAX)
@@ -683,7 +682,7 @@ static void __init smp_quirk_init_udelay(void)
 		return;
 	}
 	/* else, use legacy delay */
-	init_udelay = UDELAY_10MS_DEFAULT;
+	init_udelay = UDELAY_10MS_LEGACY;
 }
 
 /*
@@ -1094,7 +1093,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
 
 	uv_system_init();
 
-	smp_quirk_init_udelay();
+	smp_set_init_udelay();
 
 	speculative_store_bypass_ht_init();
 
-- 
2.43.0


  parent reply	other threads:[~2025-02-19 19:29 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 18:41 [PATCH v3 00/15] Prepare for new Intel Family numbers Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 01/15] x86/apic: Fix 32-bit APIC initialization for extended Intel Families Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 02/15] x86/cpu/intel: Fix the movsl alignment preference for extended Families Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 03/15] x86/microcode: Update the Intel processor flag scan check Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 04/15] x86/mtrr: Modify a x86_model check to an Intel VFM check Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 05/15] x86/cpu/intel: Replace early Family 6 checks with VFM ones Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 06/15] x86/cpu/intel: Replace Family 15 " Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 07/15] x86/cpu/intel: Replace Family 5 model " Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 08/15] x86/acpi/cstate: Improve Intel Family model checks Sohil Mehta
2025-02-20 19:20   ` Rafael J. Wysocki
2025-02-19 18:41 ` Sohil Mehta [this message]
2025-02-19 18:41 ` [PATCH v3 10/15] x86/smpboot: Fix INIT delay assignment for extended Intel Families Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 11/15] x86/cpu/intel: Fix fast string initialization for extended Families Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 12/15] x86/pat: Replace Intel x86_model checks with VFM ones Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 13/15] x86/cpu/intel: Bound the non-architectural constant_tsc model checks Sohil Mehta
2025-08-21 13:15   ` David Woodhouse
2025-08-21 19:34     ` Sohil Mehta
2025-08-21 19:43       ` Sohil Mehta
2025-08-21 20:09         ` David Woodhouse
2025-08-22  1:46         ` Xiaoyao Li
2025-08-24 22:39           ` Demi Marie Obenour
2025-02-19 18:41 ` [PATCH v3 14/15] perf/x86: Simplify Intel PMU initialization Sohil Mehta
2025-02-19 20:10   ` Liang, Kan
2025-02-19 20:31     ` Sohil Mehta
2025-02-19 20:45       ` Liang, Kan
2025-02-27  0:16   ` [PATCH v3.1 " Sohil Mehta
2025-02-19 18:41 ` [PATCH v3 15/15] perf/x86/p4: Replace Pentium 4 model checks with VFM ones Sohil Mehta
2025-02-19 20:11   ` Liang, Kan
2025-03-17 17:09 ` [PATCH v3 00/15] Prepare for new Intel Family numbers Sohil Mehta
2025-03-18 18:35   ` Ingo Molnar
2025-03-18 19:10     ` Sohil Mehta
2025-03-18 20:13       ` Ingo Molnar
2025-03-19 15:53         ` Sohil Mehta
2025-03-19 19:46           ` Ingo Molnar

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=20250219184133.816753-10-sohil.mehta@intel.com \
    --to=sohil.mehta@intel.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.laight.linux@gmail.com \
    --cc=hpa@zytor.com \
    --cc=irogers@google.com \
    --cc=jdelvare@suse.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=viresh.kumar@linaro.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).