linux-kernel - Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen

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] [thread-next>] [day] [month] [year] [list]

Message-ID: 
 <CAGwozwEp3Xc_pv-YGb_Xc46CcLKPppYaZbphV24kiNHM4Eqb-w@mail.gmail.com>
Date: Sun, 7 Dec 2025 00:35:52 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Mario Limonciello <superm1@...nel.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
 Dmitry Osipenko <dmitry.osipenko@...labora.com>,
	Robert Beckett <bob.beckett@...labora.com>, linux-acpi@...r.kernel.org,
	kernel@...labora.com, linux-kernel@...r.kernel.org,
	Sebastian Reichel <sebastian.reichel@...labora.com>,
 Xaver Hugl <xaver.hugl@...il.com>,
	Richard Hughes <richard@...hsie.com>, William Jon McCann <mccann@....edu>,
	"Jaap A . Haitsma" <jaap@...tsma.org>, Benjamin Canou <bookeldor@...il.com>,
	Bastien Nocera <hadess@...ess.net>, systemd-devel@...ts.freedesktop.org,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs
 interface

On Sat, 6 Dec 2025 at 21:50, Mario Limonciello <superm1@...nel.org> wrote:
>
> >> I will reply to the earlier reply from Rafael with more context, but
> >> runtime suspend of the GPU is not part of or related to these
> >> notifications.
> >
> > Of course it isn't.
> >
> > What we were talking about was how to get from the "displays off, no
> > GUI activity" user space smoothly into system suspend and back.
> >
> > You are saying that this has been done already on AMD, so I'm not sure
> > why you want more.
> >
>
> I'm not aware this existing in any unique way for AMD.  The decision of
> displays off; start a timer and enter suspend would be the same for any
> vendor.

AMD retains CRTC DPMS state from userspace to s0ix currently, and you
fixed hibernation recently too. Intel sometimes doesn't, the screen
will sometimes flash while entering suspend.

There is also runtime suspend on most components. Is there a case for
powering off the iGPU completely to improve energy use?

The most expensive component in this process is unfreezing, then
runtime pm freezing the GPU IP blocks after s0ix exit, then unfreezing
it two seconds later to perform runtime checks and freezing it again.
So for multiple exits from suspend where the IP is inactive this will
keep repeating.

> But GPUs aren't only used for display.  If you're actively running a
> different workload (for example an LLM) using the GPU and happen to turn
> off all the displays you wouldn't want it to suspend.
>
> What you would want is to key off:
>
> 1) All displays are off.
> 2) All GPUs are unsused.
> 3) Some time has passed.
>
> I feel that if userspace is going to adopt a policy like this kernel
> drivers need to use runtime PM when displays are off and the GPUs aren't
> being used for anything else.
>
> At least for AMD this doesn't happen today and would require driver
> work.  But the same kind of work would be needed by any GPU driver.
>

You could potentially do that, first you'd need to show that there is
a latency benefit to powering off the GPU over entering s0ix (as
userspace will be frozen in both cases for the GPU to suspend). Then,
you'd need to show that there is an energy benefit over just staying
unsuspended with userspace frozen and the GPU being in runtime
suspend. WIth both of these, a case could be made for powering off the
GPU completely for a marginal latency/energy benefit.

These notifications do not affect runtime pm though so this discussion
is a bit tangential.

Antheas