linux-kernel - Re: [PATCH] x86/mtrr: Expedite cache init if MTRRs change on resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOo6X3_5BzqKa0cwc0xYea9_+XqsFD+mgLnYDhZn5OwXeOfy_A@mail.gmail.com>
Date: Wed, 4 Feb 2026 17:25:20 +0000
From: Chris Paulson-Ellis <chris@...lson-ellis.org>
To: Jürgen Groß <jgross@...e.com>
Cc: Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/mtrr: Expedite cache init if MTRRs change on resume

On Wed, 4 Feb 2026 at 16:23, Jürgen Groß <jgross@...e.com> wrote:
>
> On 04.02.26 17:15, Chris Paulson-Ellis wrote:
> > An Apple MacBook Pro mid-2015 almost always takes ~20s to resume from
> > suspend, measured from lid open to display of the desktop lock screen.
> >
> > This is due to the MTRRs being different between suspend and resume on 4
> > out of the 8 CPUs, including the boot CPU. The CPUs execute very slowly
> > until arch_thaw_secondary_cpus_end() calls cache_aps_init(), which
> > restores the MTRR settings to their pre-suspend values.
> >
> > To obtain a reasonable resume time, we need to minimise the time the
> > CPUs execute with inconsistent MTRR settings.
> >
> > We do this by detecting the unexpected restore of the MTRRs on the boot
> > CPU in cache_bp_restore(), and use this to override the delay of cache
> > initialisation in the cache_ap_online() CPU hotplug handler, and
> > skip the delayed cache initialisation in cache_aps_init().
> >
> > With this fix, the system in question resumes in ~3s.
>
> Does it get even better with my still pending series [1] applied?
>
> [1]: https://lore.kernel.org/lkml/20260130113625.599305-1-jgross@suse.com/

Hi Juergen,

Thanks for looking at this.

Naturally our patches conflict. I resolved & tested it, and the time
to the completion of AP bring-up went from 90ms to 80ms (it's >10s
without my changes). So maybe, although the difference is probably
within the measurement margin of error.

I you want to try it yourself on your big iron, you can see our
combined changes here:
https://github.com/cgpe-a/linux/commits/mtrr-resume-fix-3/

Chris.