If you want consistent low latency dropping in and out of sleep state
does not help. But putting a deadline oriented task - like networking
- on a smaller processor, seems like it might work.
On Mon, Jun 1, 2020 at 9:02 AM Michael Richardson <m...@sandelman.ca> wrote:
>
> 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 [
> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails
> [
>
--
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman
d...@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
