Message-ID: <alpine.DEB.2.11.1809131041000.11646@lakka.kapsi.fi>
Date:   Thu, 13 Sep 2018 11:41:31 +0300 (EEST)
From:   Sampo Syreeni <decoy@....fi>
To:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: about timer API's/a possible development idea

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@....fi, http://decoy.iki.fi/front
+358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Powered by blists - more mailing lists