lkml.org 
[lkml]   [2018]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectabout 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@iki.fi, http://decoy.iki.fi/front
+358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

\
 
 \ /
  Last update: 2018-09-13 10:42    [W:0.030 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site