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

Pranav Prasad
2024-02-07T17:17:04Z

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
> >