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

[Pranav Prasad]

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