From: Dave Taht <dave.taht@gmail.com>
To: Michael Richardson <mcr@sandelman.ca>
Cc: bloat <bloat@lists.bufferbloat.net>,
cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Bloat] capacity awareness for the deadline scheduler
Date: Mon, 1 Jun 2020 13:31:05 -0700 [thread overview]
Message-ID: <CAA93jw7+sU7hJ7vkO9LwRehtChnmZaWe4dJqiZeThrngqFp-nA@mail.gmail.com> (raw)
In-Reply-To: <19625.1591027325@localhost>
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 <mcr@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 [
> ] mcr@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
dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729
prev parent reply other threads:[~2020-06-01 20:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-31 21:39 Dave Taht
2020-06-01 15:58 ` Michael Richardson
2020-06-01 20:35 ` Dave Taht
2020-06-01 16:02 ` Michael Richardson
2020-06-01 20:31 ` Dave Taht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw7+sU7hJ7vkO9LwRehtChnmZaWe4dJqiZeThrngqFp-nA@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=mcr@sandelman.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox