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 2:06 AM Pranav Prasad <pranavpp@google.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
>

On Wed, Feb 7, 2024 at 2:06 AM Pranav Prasad <pranavpp@google.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@google.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@google.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
> >