By: Doug S (foo.delete@this.bar.bar), September 13, 2021 8:53 pm
Room: Moderated Discussions
David Hess (davidwhess.delete@this.gmail.com) on September 13, 2021 3:28 pm wrote:
> Doug S (foo.delete@this.bar.bar) on September 13, 2021 3:05 pm wrote:
> >
> > Allowing apps to determine where their threads should run would be like turning back the
> > clock to the cooperative multitasking days. You have to rely on all apps being "good citizens"
> > which is simply not realistic. Even if you 'reviewing' apps manually like Apple you can't
> > possible test all the corner cases, and do a full re-test for every update.
>
> In my post, I almost made the comparison with cooperative multitasking
> but thought it might be a little too much. :)
>
> The hard real time operating systems that I am familiar with only
> manage it with considerable input from the application developer.
In some ways this problem is sort of like that faced by hard real time systems, and the solution is probably similar. A deadline scheduler that allows the application to say "I need this done by time X" where X might be before the next screen refresh or before the arrival of the next data block from storage could let the application communicate what it needs and allow the OS to determine the best way to make that happen.
You still have the same problem, if an app always says "I need this done ASAP" for everything, but that's less likely since the app will have things dependent on human response time, on something coming from the internet, etc. There's nothing to be gained by requesting minimum latency, so long as you trust the scheduler to meet the deadline.
The nice thing is that unlike a hard realtime system a smartphone's deadline scheduler wouldn't need to ALWAYS get it right. If fails to meet the deadline once in every 10,000 times it isn't going to be a big deal. Maybe you see a slight screen tear in a game once every few hours, that's acceptable for a smartphone unlike say an automotive ECU or the system that operates the control surfaces of a modern aerodynamically unstable fighter jet.
> Doug S (foo.delete@this.bar.bar) on September 13, 2021 3:05 pm wrote:
> >
> > Allowing apps to determine where their threads should run would be like turning back the
> > clock to the cooperative multitasking days. You have to rely on all apps being "good citizens"
> > which is simply not realistic. Even if you 'reviewing' apps manually like Apple you can't
> > possible test all the corner cases, and do a full re-test for every update.
>
> In my post, I almost made the comparison with cooperative multitasking
> but thought it might be a little too much. :)
>
> The hard real time operating systems that I am familiar with only
> manage it with considerable input from the application developer.
In some ways this problem is sort of like that faced by hard real time systems, and the solution is probably similar. A deadline scheduler that allows the application to say "I need this done by time X" where X might be before the next screen refresh or before the arrival of the next data block from storage could let the application communicate what it needs and allow the OS to determine the best way to make that happen.
You still have the same problem, if an app always says "I need this done ASAP" for everything, but that's less likely since the app will have things dependent on human response time, on something coming from the internet, etc. There's nothing to be gained by requesting minimum latency, so long as you trust the scheduler to meet the deadline.
The nice thing is that unlike a hard realtime system a smartphone's deadline scheduler wouldn't need to ALWAYS get it right. If fails to meet the deadline once in every 10,000 times it isn't going to be a big deal. Maybe you see a slight screen tear in a game once every few hours, that's acceptable for a smartphone unlike say an automotive ECU or the system that operates the control surfaces of a modern aerodynamically unstable fighter jet.
Topic | Posted By | Date |
---|---|---|
alder lake. | inteluser | 2021/09/10 01:52 AM |
alder lake. | Andrei F | 2021/09/10 09:31 AM |
alder lake. | Andrey | 2021/09/10 09:38 AM |
alder lake. | rwessel | 2021/09/10 11:18 AM |
alder lake. | Andrei F | 2021/09/10 12:49 PM |
alder lake. | Andrey | 2021/09/10 04:12 PM |
alder lake. | David Hess | 2021/09/10 07:39 PM |
alder lake. | Andrey | 2021/09/11 12:28 AM |
alder lake. | --- | 2021/09/10 05:24 PM |
alder lake. | Andrei F | 2021/09/12 01:09 AM |
DVFS | David Kanter | 2021/09/12 09:58 PM |
DVFS | Andrei F | 2021/09/13 01:02 AM |
DVFS | Anon | 2021/09/13 03:28 AM |
DVFS | Jukka Larja | 2021/09/13 05:35 AM |
DVFS | Andrei F | 2021/09/14 12:07 AM |
DVFS | Jukka Larja | 2021/09/14 04:11 AM |
DVFS | Andrei F | 2021/09/14 07:55 AM |
DVFS | Jukka Larja | 2021/09/14 10:23 AM |
DVFS | --- | 2021/09/13 10:19 AM |
DVFS | Doug S | 2021/09/13 10:57 AM |
DVFS | David Hess | 2021/09/13 11:32 AM |
DVFS | --- | 2021/09/13 01:06 PM |
DVFS | David Hess | 2021/09/13 02:21 PM |
DVFS | David Kanter | 2021/09/15 03:05 PM |
DVFS | David Hess | 2021/09/13 11:46 AM |
DVFS | Jukka Larja | 2021/09/14 04:35 AM |
Quick shutdown? | David Kanter | 2021/09/15 10:46 AM |
Quick shutdown? | Andrei F | 2021/09/16 07:12 AM |
Quick shutdown? | David Kanter | 2021/09/16 11:04 AM |
Quick shutdown? | Andrei F | 2021/09/17 01:35 AM |
Quick shutdown? | Andrei F | 2021/09/17 01:38 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 04:20 AM |
and weren't 'they' right? | Andrei F | 2021/09/13 04:51 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 06:29 AM |
and weren't 'they' right? | anon | 2021/09/13 05:07 AM |
and weren't 'they' right? | Jukka Larja | 2021/09/13 05:26 AM |
and weren't 'they' right? | anon | 2021/09/13 11:37 PM |
Alder Lake has no little cores | Heikki Kultala | 2021/09/13 06:33 AM |
Alder Lake has no little cores | Michael S | 2021/09/13 07:33 AM |
Alder Lake has no little cores | me | 2021/09/13 10:45 AM |
Alder Lake has no little cores | Heikki Kultala | 2021/09/13 01:49 PM |
Alder Lake has no little cores | anon | 2021/09/13 11:42 PM |
why stop at two core sizes? | hobold | 2021/09/14 05:47 AM |
Memory caches did this, right? | Mark Roulo | 2021/09/14 02:51 PM |
Memory caches did this, right? | Brett | 2021/09/14 07:17 PM |
Memory caches did this, right? | Kevin G | 2021/09/16 03:10 PM |
Large reorder buffers (L1+L2) | ⚛ | 2021/09/15 11:24 AM |
Large reorder buffers (L1+L2) | hobold | 2021/09/15 12:06 PM |
Alder Lake has no little cores | Adrian | 2021/09/14 08:33 AM |
and weren't 'they' right? | David Hess | 2021/09/13 12:00 PM |
Battery vs Performance | Mark Roulo | 2021/09/13 12:18 PM |
Battery vs Performance | Doug S | 2021/09/13 02:05 PM |
Battery vs Performance | David Hess | 2021/09/13 02:28 PM |
Battery vs Performance | --- | 2021/09/13 05:08 PM |
Battery vs Performance | --- | 2021/09/13 05:08 PM |
Battery vs Performance | Doug S | 2021/09/13 08:53 PM |
Battery vs Performance | Anon | 2021/09/14 06:42 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 12:57 PM |
and weren't 'they' right? | David Hess | 2021/09/13 02:11 PM |
and weren't 'they' right? | --- | 2021/09/13 02:38 PM |
and weren't 'they' right? | --- | 2021/09/13 02:32 PM |
and weren't 'they' right? | Brendan | 2021/09/14 03:30 AM |
and weren't 'they' right? | Jukka Larja | 2021/09/14 04:31 AM |
and weren't 'they' right? | Etienne Lorrain | 2021/09/14 12:29 AM |