Received-SPF: pass (google.com: domain of linux-kernel+bounces-56818-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20240207100619.3947442-1-pranavpp@google.com> <CACkwYU02EBFet1LgJR29UkLs4gkWck1rnVP7kz+Gti0aAVP_cg@mail.gmail.com>
In-Reply-To: <CACkwYU02EBFet1LgJR29UkLs4gkWck1rnVP7kz+Gti0aAVP_cg@mail.gmail.com>
From: Pranav Prasad <pranavpp@google.com>
Date: Wed, 7 Feb 2024 09:16:51 -0800
Message-ID: <CACkwYU1UUhanBVEEZSaNupXEod4QR-mDBCnWjHZSQyuLzzCv9w@mail.gmail.com>
Subject: Re: [PATCH 0/2] alarmtimer: Rework the suspend flow in alarmtimer
To: tglx@linutronix.de, jstultz@google.com, sboyd@kernel.org
Cc: linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 7, 2024 at 2:06=E2=80=AFAM 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 amoun=
t
> 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, th=
e
> imminent alarm that caused the failure was likely already scheduled befor=
e
> suspend even started. This provides an opportunity to reduce power
> consumption if the suspend failure decision is made earlier in the suspen=
d
> 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 fix=
es.

Pranav

On Wed, Feb 7, 2024 at 8:46=E2=80=AFAM Pranav Prasad <pranavpp@google.com> =
wrote:
>
> Please ignore this patch series, submitting v2 with some more suggested f=
ixes.
>
> Pranav
>
> On Wed, Feb 7, 2024 at 2:06=E2=80=AFAM 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 an=
d
> > 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 secon=
ds,
> > the alarmtimer driver fails to suspend. In this case, a non-trivial amo=
unt
> > 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 bef=
ore
> > suspend even started. This provides an opportunity to reduce power
> > consumption if the suspend failure decision is made earlier in the susp=
end
> > 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 suspen=
d
> >     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
> >