[Bloat] capacity awareness for the deadline scheduler

[Michael Richardson]

article points out:

> The work of the deadline scheduler becomes more complicated in asymmetric
> CPU configurations, like big.LITTLE or DynamIQ. Such systems include
> different types of CPUs, with higher and lower performance. The same task
> running on a higher-performance ("big") CPU will take less time than when
> run on a lower-performance ("little") one. The deadline scheduler in
> current kernels does not take that difference into account, with the result
> that it can over-allocate the CPU time on lower-performance CPUs. Deadline
> tasks could end up on a little CPU, scheduled in such a way that they are
> unable to finish before their deadlines, while they would be able to do so
> on a higher-performance CPU. On such systems, the admission-control
> algorithm, which assumes that all CPUs perform at the level of the big
> ones, could overcommit the system with deadline tasks, making the system
> unusable.

and I wonder if in some cases it is better to keep a "little" CPU (which
presumably draws a lot less power) running continuously to deal with
deadlines than it is to wake up the "big" CPU to do stuff.

I understand that we learnt the opposite in the early days of Mobile CPUs: it
was best to run the CPU as fast (and hot) as possible to finish early and
suspend.  Sometimes it was even power-wise to turn the fan on.

But CPU-fast/sleep-long-time would lead to a high jitter on events that one
might want to be more regular.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [