Re: [PATCH] alarmtimer: Expose information about next alarm to userspace via sysfs

[John Stultz]

On Thu, Jan 18, 2024 at 10:15 AM Pranav Prasad <pranavpp@xxxxxxxxxx> 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 before
> the suspend fails and additional work afterwards to undo the failed suspend
> that was attempted. Therefore on battery-powered devices that initiate suspend
> attempts from userspace, it may be advantageous to be able to skip the entire
> suspend attempt to avoid power consumption instead of unnecessarily trying and
> failing. As one data point, an analysis of a subset of Android devices showed that
> imminent alarms account for roughly 40% of all suspend failures on average 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