about timer API's/a possible development idea

From: Sampo Syreeni
Date: Thu Sep 13 2018 - 04:41:59 EST

Hi. I'm new to the kernel, but I'd still like to ask a question. Can it sleep(3) or somesuch higher resolution version, *without* deterministically waking my process up? Are there API's which enable you to state to the scheduler: "I'd *like* to be woken up 100ms from here, *but* it's okay if you hold off for a minute for your own higher purposes"?

If there already is an interface which lets me communicate something like that to the scheduler, my point is moot; forget about everything I'm about to say.

However, if no such API exists, I'd like to argue why it would be useful. Perchance even necessary, and via incorporation into the Linux and then the Android kernel, something worthy of POSIX standardization.

My point is that quite a number of applications like phones' radios and even your common Intel microprocessors rely on being able to switch off or throttle back, intermittently, in order to conserve power and/or heat. That can only happen if those chips have nothing to do.

Scheduled wakeups make-do for the chips, and especially so if they happen at random intervals. That's the dearth of *my* phone's battery at least: constant wakeups from a ton of background apps.

While I don't know *what* those apps are doing for real, I suspect most of them are spinning in a while(1) {do-polling; do-advertising; sleep(arbitrary-time-constaant);} -kinda loop. So that in toto they end up waking up my kernel, and when online even my radio, pretty much all the time.

A rather simple means of stopping that sort of behavior would be to enable -- not just simple sleep -- but sleep with tolerance. Most of those problematic apps don't really need to be woken up *precisely* 100ms from here, to poll something. They'd be just as well if they were woken up a second from now, or even a minute. Yet they might not be able to communicaate that to the scheduler right now.

If they could, the scheduler could suddenly batch up operations over multiple applications. It could not only wake up cores and do batch optimization over the processes woken, but it could also only wake up the costly-in-battery-and-latency radio transmitter of your mobile just when it has to. Say, in the polling interval of the many low power radio protocols which we nowadays have.

Again, I don't know pretty much anything about kernel development, or the extant low level API's Linux people have. But I do know something like this would be useful, and easy to interface towards any extant no-tick scheduler. *NIX-kernel-wise and POSIX-wise even it would be rather a simple exercise to just overload any blocking calls which carry a deadline with a second call, taking two arguments instead of one. The second one being the actual deadline, and the first one being what we now experience under POSIX rules. Between those two, the scheduler would have much more latitude for optimization.

Such calls could be aliased back from sleep(x,y) to just the current sleep(x) without loss of functionality. The second time argument could be treated as a hint, even formally, with no loss of functionality. However when implemented, that hint could yield real efficiency gains in heat expenditure, battery life, and maybe even processing latency, since it *does* constitute a kind of implicit barrier device.

Please tell me someone implemented something like that already, and it's on its way to standardization? If not, please tell me some of you are interested in the idea.
Sampo Syreeni, aka decoy - decoy@xxxxxx, http://decoy.iki.fi/front
+358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2