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

[Chris Paulson-Ellis]

On Wed, 4 Feb 2026 at 16:23, Jürgen Groß <jgross@xxxxxxxx> 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@xxxxxxxx/

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.