linux-kernel - Re: [PATCH 0/2] alarmtimer: Rework the suspend flow in alarmtimer

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: <CACkwYU1UUhanBVEEZSaNupXEod4QR-mDBCnWjHZSQyuLzzCv9w@mail.gmail.com>
Date: Wed, 7 Feb 2024 09:16:51 -0800
From: Pranav Prasad <pranavpp@...gle.com>
To: tglx@...utronix.de, jstultz@...gle.com, sboyd@...nel.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] alarmtimer: Rework the suspend flow in alarmtimer

On Wed, Feb 7, 2024 at 2:06 AM Pranav Prasad <pranavpp@...gle.com> wrote:
>
> Hi!
>
> During the driver suspend phase of kernel suspend, alarmtimer's suspend
> callback is invoked and it identifies the earliest next wakeup alarm and
> programs that into the HW real time clock (RTC). However, there is an
> exception to this process. If the next alarm is within the next 2 seconds,
> the alarmtimer driver fails to suspend. In this case, a non-trivial amount
> of power is spent to freeze and unfreeze all userspace processes and to
> suspend and resume a number of devices. In the vast majority of cases, the
> imminent alarm that caused the failure was likely already scheduled before
> suspend even started. This provides an opportunity to reduce power
> consumption if the suspend failure decision is made earlier in the suspend
> flow before the unnecessary extra work is done. This patch series aims to
> achieve a kernel suspend flow in which the check for an imminent alarm is
> performed early during the suspend prepare phase.
>
> Pranav Prasad (2):
>   alarmtimer: Create alarmtimer sysfs to make duration of kernel suspend
>     check configurable
>   alarmtimer: Modify alarmtimer suspend callback to check for imminent
>     alarm using PM notifier
>
>  kernel/time/alarmtimer.c | 178 +++++++++++++++++++++++++++++++--------
>  1 file changed, 144 insertions(+), 34 deletions(-)
>
> --
> 2.43.0.594.gd9cf4e227d-goog
>

Please ignore this patch series, submitting v2 with some more suggested fixes.

Pranav

On Wed, Feb 7, 2024 at 8:46 AM Pranav Prasad <pranavpp@...gle.com> wrote:
>
> Please ignore this patch series, submitting v2 with some more suggested fixes.
>
> Pranav
>
> On Wed, Feb 7, 2024 at 2:06 AM Pranav Prasad <pranavpp@...gle.com> wrote:
> >
> > Hi!
> >
> > During the driver suspend phase of kernel suspend, alarmtimer's suspend
> > callback is invoked and it identifies the earliest next wakeup alarm and
> > programs that into the HW real time clock (RTC). However, there is an
> > exception to this process. If the next alarm is within the next 2 seconds,
> > the alarmtimer driver fails to suspend. In this case, a non-trivial amount
> > of power is spent to freeze and unfreeze all userspace processes and to
> > suspend and resume a number of devices. In the vast majority of cases, the
> > imminent alarm that caused the failure was likely already scheduled before
> > suspend even started. This provides an opportunity to reduce power
> > consumption if the suspend failure decision is made earlier in the suspend
> > flow before the unnecessary extra work is done. This patch series aims to
> > achieve a kernel suspend flow in which the check for an imminent alarm is
> > performed early during the suspend prepare phase.
> >
> > Pranav Prasad (2):
> >   alarmtimer: Create alarmtimer sysfs to make duration of kernel suspend
> >     check configurable
> >   alarmtimer: Modify alarmtimer suspend callback to check for imminent
> >     alarm using PM notifier
> >
> >  kernel/time/alarmtimer.c | 178 +++++++++++++++++++++++++++++++--------
> >  1 file changed, 144 insertions(+), 34 deletions(-)
> >
> > --
> > 2.43.0.594.gd9cf4e227d-goog
> >