Received-SPF: pass (google.com: domain of linux-kernel+bounces-30595-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240118181459.1663313-1-pranavpp@google.com>
In-Reply-To: <20240118181459.1663313-1-pranavpp@google.com>
From: John Stultz <jstultz@google.com>
Date: Thu, 18 Jan 2024 14:11:49 -0800
Message-ID: <CANDhNCqyugdsais9bzaL8RxTxyBgme4W2ZdfayaS8HbqBHJraw@mail.gmail.com>
Subject: Re: [PATCH] alarmtimer: Expose information about next alarm to
 userspace via sysfs
To: Pranav Prasad <pranavpp@google.com>
Cc: tglx@linutronix.de, sboyd@kernel.org, linux-kernel@vger.kernel.org, 
	Kelly Rossmoyer <krossmo@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 18, 2024 at 10:15=E2=80=AFAM Pranav Prasad <pranavpp@google.com=
> wrote:
>
> The alarmtimer driver currently fails suspend attempts when there is an
> alarm pending within the next 2 seconds, since the system is expected to =
wake
> up soon anyway. The entire suspend process is initiated even though the
> system will immediately awaken. This process includes substantial work be=
fore
> the suspend fails and additional work afterwards to undo the failed suspe=
nd
> that was attempted. Therefore on battery-powered devices that initiate su=
spend
> attempts from userspace, it may be advantageous to be able to skip the en=
tire
> suspend attempt to avoid power consumption instead of unnecessarily tryin=
g and
> failing. As one data point, an analysis of a subset of Android devices sh=
owed that
> imminent alarms account for roughly 40% of all suspend failures on averag=
e leading
> to unnecessary power wastage.
>

So thanks for sending this out!

  I'm always a bit cautious when exposing stuff to userland,
particularly if it's potentially racy as you mentioned in your
description. One thought I had was might adding a similar check
earlier in the suspend path on the kernel side provide similar benefit
(without requiring userland changes)?

Basically, if I understand the problem:
echo mem > /sys/power/state
<kernel goes through suspending everything>
alarmtimer_suspend()
  if (next_alarm < TWO_SECONDS)
      return -EBUSY;
<kernel has to resume everything, and all that time was wasted>

So if instead we did:
echo mem > /sys/power/state
enter_state()
   if (alarmtimer_immenent())
      retrun -EBUSY

So the kernel would come back much faster if the suspend was going to abort=
.

I suspect you all have considered this already but wanted to
understand what issues that approach has.

thanks
-john