Messages in this thread | | | From | John Stultz <> | Date | Thu, 18 Jan 2024 14:11:49 -0800 | Subject | Re: [PATCH] alarmtimer: Expose information about next alarm to userspace via sysfs |
| |
On Thu, Jan 18, 2024 at 10:15 AM 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 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
| |