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

[Mario Limonciello <superm1@kernel.org>]

On 11/6/26 10:57, Rafael J. Wysocki (Intel) wrote:
> On Mon, Nov 2, 2026 at 2:54 PM Mario Limonciello <superm1@kernel.org> 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@amd.com/#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.