| Message ID | a4aa8842a3c3bfdb7fe9807710eef159cbf0e705.1731463305.git.len.brown@intel.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | [v3] x86/cpu: Add INTEL_LUNARLAKE_M to X86_BUG_MONITOR | expand |
On Wed, Nov 13, 2024 at 3:07 AM Len Brown <lenb@kernel.org> wrote: > > From: Len Brown <len.brown@intel.com> > > Under some conditions, MONITOR wakeups on Lunar Lake processors > can be lost, resulting in significant user-visible delays. > > Add LunarLake to X86_BUG_MONITOR so that wake_up_idle_cpu() > always sends an IPI, avoiding this potential delay. > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219364 > > Cc: stable@vger.kernel.org # 6.11 > Signed-off-by: Len Brown <len.brown@intel.com> Still Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > v3 syntax tweak > v2 leave smp_kick_mwait_play_dead() alone > > arch/x86/kernel/cpu/intel.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c > index e7656cbef68d..4b5f3d052151 100644 > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -586,7 +586,9 @@ static void init_intel(struct cpuinfo_x86 *c) > c->x86_vfm == INTEL_WESTMERE_EX)) > set_cpu_bug(c, X86_BUG_CLFLUSH_MONITOR); > > - if (boot_cpu_has(X86_FEATURE_MWAIT) && c->x86_vfm == INTEL_ATOM_GOLDMONT) > + if (boot_cpu_has(X86_FEATURE_MWAIT) && > + (c->x86_vfm == INTEL_ATOM_GOLDMONT || > + c->x86_vfm == INTEL_LUNARLAKE_M)) > set_cpu_bug(c, X86_BUG_MONITOR); > > #ifdef CONFIG_X86_64 > -- > 2.43.0 >
On 11/12/24 18:07, Len Brown wrote: > From: Len Brown <len.brown@intel.com> > > Under some conditions, MONITOR wakeups on Lunar Lake processors > can be lost, resulting in significant user-visible delays. > > Add LunarLake to X86_BUG_MONITOR so that wake_up_idle_cpu() > always sends an IPI, avoiding this potential delay. This kinda implies that X86_BUG_MONITOR only does one thing. What about the two other places in the tree that check it. Are those relevant? > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219364 > > Cc: stable@vger.kernel.org # 6.11 > Signed-off-by: Len Brown <len.brown@intel.com> This obviously conflicts with the VFM infrastructure, but shouldn't this also get backported to even older stable kernels? I thought the "# 6.11" was to tell folks where it is *needed*, not where it actually applies.
On Wed, Nov 20, 2024 at 8:12 PM Dave Hansen <dave.hansen@intel.com> wrote: > > On 11/12/24 18:07, Len Brown wrote: > > From: Len Brown <len.brown@intel.com> > > > > Under some conditions, MONITOR wakeups on Lunar Lake processors > > can be lost, resulting in significant user-visible delays. > > > > Add LunarLake to X86_BUG_MONITOR so that wake_up_idle_cpu() > > always sends an IPI, avoiding this potential delay. > > This kinda implies that X86_BUG_MONITOR only does one thing. What about > the two other places in the tree that check it. Are those relevant? They are relevant, but related. The first one prevents mwait_idle() from becoming the default idle function, which only matters if cpuidle is not used, but this is consistent with the mwait_idle_with_hints() behavior. The second one prevents KVM from using MWAIT in the guest which I would think is a good idea in this case. > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219364 > > > > Cc: stable@vger.kernel.org # 6.11 > > Signed-off-by: Len Brown <len.brown@intel.com> > > This obviously conflicts with the VFM infrastructure, but shouldn't this > also get backported to even older stable kernels? As a matter of principle, it should go to all of the stable kernel series still in use, but it obviously needs backporting and I'm not really sure how attractive the old kernel series will be for LNL users (quite likely not at all). > I thought the "# 6.11" was to tell folks where it is *needed*, not where > it actually applies. My interpretation is slightly different: This is the oldest series one wants the given patch to go to.
On 11/20/24 12:08, Rafael J. Wysocki wrote: >>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219364 >>> >>> Cc: stable@vger.kernel.org # 6.11 >>> Signed-off-by: Len Brown <len.brown@intel.com> >> This obviously conflicts with the VFM infrastructure, but shouldn't this >> also get backported to even older stable kernels? > As a matter of principle, it should go to all of the stable kernel > series still in use, but it obviously needs backporting and I'm not > really sure how attractive the old kernel series will be for LNL users > (quite likely not at all). I'm not going to lose sleep over it, but as a policy, I think we should backport CPU fixes to all the stable kernels. I don't feel like I have a good enough handle on what kernels folks run on new systems to make a prediction.
On Wed, Nov 20, 2024 at 3:21 PM Dave Hansen <dave.hansen@intel.com> wrote: > I'm not going to lose sleep over it, but as a policy, I think we should > backport CPU fixes to all the stable kernels. I don't feel like I have a > good enough handle on what kernels folks run on new systems to make a > prediction. FWIW, I sent a backport of a slightly earlier version of this patch, but all I got back was vitriol about violating the kernel Documentation on sending to stable. Maybe a native english speaker could re-write that Documentation, so that a native english speaker can understand it? Or better yet, somebody can write a script or update checkpatch so that developers can more likely avoid the Soup Nazi treatment? ie. I agree with you, and I'm happy to help, but it isn't clear how. Len Brown, Intel
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index e7656cbef68d..4b5f3d052151 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -586,7 +586,9 @@ static void init_intel(struct cpuinfo_x86 *c) c->x86_vfm == INTEL_WESTMERE_EX)) set_cpu_bug(c, X86_BUG_CLFLUSH_MONITOR); - if (boot_cpu_has(X86_FEATURE_MWAIT) && c->x86_vfm == INTEL_ATOM_GOLDMONT) + if (boot_cpu_has(X86_FEATURE_MWAIT) && + (c->x86_vfm == INTEL_ATOM_GOLDMONT || + c->x86_vfm == INTEL_LUNARLAKE_M)) set_cpu_bug(c, X86_BUG_MONITOR); #ifdef CONFIG_X86_64