[Cerowrt-devel] capacity awareness for the deadline scheduler

[Cerowrt-devel] capacity awareness for the deadline scheduler

[Dave Taht]

Gradually, people seem to be getting more and more about basic queue theory.

https://lwn.net/SubscriberLink/821578/ef5d913a20977921/

-- 
"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

Re: [Cerowrt-devel] [Bloat] capacity awareness for the deadline scheduler

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]


Dave Taht <dave.taht@gmail.com> wrote:
    > Gradually, people seem to be getting more and more about basic queue theory.
    > https://lwn.net/SubscriberLink/821578/ef5d913a20977921/

Having skimmed the article, which seems to be mostly about CPU scheduling, I
have a question.

Does the availability of better *CPU* scheduling make it easier to do better
TCP pacing?  Maybe that was your entire point?

--
]               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    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [Cerowrt-devel] [Bloat] capacity awareness for the deadline scheduler

[Dave Taht]

On Mon, Jun 1, 2020 at 8:58 AM Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Dave Taht <dave.taht@gmail.com> wrote:
>     > Gradually, people seem to be getting more and more about basic queue theory.
>     > https://lwn.net/SubscriberLink/821578/ef5d913a20977921/
>
> Having skimmed the article, which seems to be mostly about CPU scheduling, I
> have a question.
>
> Does the availability of better *CPU* scheduling make it easier to do better
> TCP pacing?  Maybe that was your entire point?

It wasn't my entire point, it's just that I'm pleased to see more and
more progress in more people more deeply understanding kleinrocks
work.

as one example, pie's default rate estimator tends to go to hell in
the presence of jitter - be it induced by cpu scheduling, offloads,
pulling stuff off the rx ring, or putting it on the tx ring. A fixed
version of pie is documented here:
https://www.sciencedirect.com/science/article/abs/pii/S1389128619313775
. All I knew at the time pie was being developed was that it didn't
work well with hw multiqueue, I was not
aware the rate estimator problem was more general.

it worries me that pie is being naively applied to cable modem tech as
this problem does not show up in simple simulations.
>
> --
> ]               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

Re: [Cerowrt-devel] [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@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Cerowrt-devel] [Bloat] capacity awareness for the deadline scheduler

[Dave Taht]

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