Re: [PATCH 0/2] Use hibernate callbacks when shutting down the system

[Mario Limonciello]

On 11/6/26 10:57, Rafael J. Wysocki (Intel) wrote:
> On Mon, Nov 2, 2026 at 2:54 PM Mario Limonciello <superm1@xxxxxxxxxx> wrote:
> > OEM systems that ship with Linux preloaded need to go through energy
> > certifications that match regulatory bodies in the regions that they
> > will ship.
> >
> > If any of those certifications don't pass then OEMs might not be able
> > to ship systems preloaded in applicable regions.
> >
> > Multiple models of systems are reported to fail in Linux but pass
> > for Windows on the exact same hardware.
> >
> > By looking at a breakdown of power consumption across devices the
> > issue is that some devices aren't turned off when user puts the
> > system into S5 (shutdown).
> >
> > A few years ago when I first root caused this I submitted patches
> > to PCI core to change the PCI policy at shutdown [1].
> >
> > But through various iterations I've come up with a better approach.
> > Instead of changing policy in each subsystem we can instead
> > change our shutdown command to run hibernate callbacks for all hardware.
> >
> > In order to accomplish that the last 17 kernel cycles I've been slowly
> > drippping changes into the hibernate code paths of all subsystems to make
> > sure they behave as intended.
> >
> > Those are all merged as of kernel 7.4-rc1, and thus I am now ready to
> > start using the hibernate codepath at shutdown. This series adds that
> > support.
> >
> > I'm not naïve; there is definitely risk involved with this change as it
> > will essentially affect anything running Linux that gets turned off.
> >
> > To that I will say that I have been running, rebasing and iterating this
> > series on my personal development tree ever since December 2023.
> > Various rolling distro community members have also been testing iterations
> > of these patches in their hardware and distros.
> >
> > I've also put a few guard rails in place:
> >
> > 1. Don't mandate hibernate support. If not compiled with it, just use
> >     previous shutdown paths.
> > 2. If hibernate callback fail, emit a `pr_emerg()` message but fallback
> >     to previous shutdown paths.
> > 3. Offer a kernel command line option `shutdown=legacy` that any affected
> >     user could use to roll back to previous behavior while we root cause
> >     any issues.
> >
> > I did split out the kernel command line option to a second commit.  If we
> > later decide that we want to keep this behavior but drop the rollback knob
> > we can revert that commit.
> >
> > Link: https://lore.kernel.org/linux-pci/20231213182656.6165-1-mario.limonciello@xxxxxxx/#t
>
> I have a couple of concerns regarding this, after looking at the patches.
>
> First off, dpm_suspend_start() seems to be called during shutdown
> while user space is running.  That is risky because at least some
> things in the power-off code path assume that user space has been
> frozen.  I think that freezing tasks, along the lines of what system
> suspend does, before running dpm_suspend_start(), is requisite or you
> will get into trouble with people who run fuzzers across shutdown or
> similar.

Hmm.  I'll see about adding that to this path, thanks.

> The other concern is that the "legacy" shutdown should be the default
> or people will get confused.  Arguably, it is not even necessary to
> try to change that in many cases.
>
> Of course, this means that the new shutdown arrangement will not be
> used to start with, so there needs to be a plan to migrate users to
> this new order and I would start with the systems where it actually is
> an improvement.

It's improved every system I've tried and measured; but the level of 
improvement comes down to what hardware is contained.

The most demonstrable improvement comes from systems with dGPUs.

> I would try to add the shutdown= option upfront in the first patch and
> make it take one of two options, "classic" (the regular shutdown
> callbacks) or "pm-aware" (hibernation callbacks etc) with the first
> one being the default at least to start with.

OK.

> Then, you can add a DMI quirk table or similar with a list of systems
> where "pm-aware" works better than "classic" and expand its use going
> forward.  My expectation would be that, at one point in time, the
> majority of x86 platforms using ACPI would be better off with
> "pm-aware" than with "classic", but I'm not sure that this point in
> time is today.  Beyond that, it is really hard to say how cards will
> fall.

How would you feel about a heuristic to turn it on for anything with > 1 
GPU/accelerator for now?  I think that's the biggest bang for the buck 
right now.

But deciding when/how to turn it on for more systems than that I think 
is going to require a wider call for testing.