From: Benjamin Cronce <bcronce@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Dave Taht <dave.taht@gmail.com>,
"cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>,
Eric Luehrsen <ericluehrsen@hotmail.com>
Subject: Re: [Cake] [LEDE-DEV] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
Date: Mon, 6 Mar 2017 12:08:59 -0600 [thread overview]
Message-ID: <CAJ_ENFF4jgjwo+1or8OMesH4j8UAHob9mOh+DEMP0X_a9+6GAw@mail.gmail.com> (raw)
In-Reply-To: <43E2473F-9DFC-48D4-A4E2-A41802E8004F@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
Depends on how short of a timescale you're talking about. Shared global
state that is being read and written to very quickly by multiple threads is
bad enough for a single package system, but when you start getting to
something like an AMD Ryzen or NUMA, shared global state becomes really
expensive. Accuracy is expensive. Loosen the accuracy and gain scalability.
I would be interested in the pseduo-code or high level of what state needs
to be shared and how that state is used.
I was also thinking more of some hybrid. Instead of a "token" representing
a bucked amount of bandwidth that can be immediately used, I was thinking
more of like a "future" of bandwidth that could be used. So instead of
saying "here's a token of bandwidth", you have each core doing it's own
deficit bandwidth shaping, but when a token is received, a core can
temporarily increase its assigned shaping bandwidth. If I remember
correctly, cake already supports having its bandwidth changed on the fly.
Of course it may be simpler to say cake is meant to be used on no more than
8 cores with a non-numa CPU system with all cores having a shared
low-latency cache connecting the cores.
On Mon, Mar 6, 2017 at 8:44 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:
>
> > On 6 Mar, 2017, at 15:30, Benjamin Cronce <bcronce@gmail.com> wrote:
> >
> > You could treat it like task stealing, except each core can generate
> tokens that represent a quantum of bandwidth that is only valid for some
> interval.
>
> You’re obviously thinking of a token-bucket based shaper here. CAKE uses
> a deficit-mode shaper which deliberately works a different way - it’s more
> accurate on short timescales, and this actually makes a positive difference
> in several important cases.
>
> The good news is that there probably is a way to explicitly and
> efficiently share bandwidth in any desired ratio across different CAKE
> instances, assuming a shared-memory location can be established. I don’t
> presently have the mental bandwidth to actually try doing that, though.
>
> - Jonathan Morton
>
>
[-- Attachment #2: Type: text/html, Size: 2641 bytes --]
next prev parent reply other threads:[~2017-03-06 18:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <e955b05f85fea5661cfe306be0a28250@inventati.org>
[not found] ` <07479F0A-40DD-44E5-B67E-28117C7CF228@gmx.de>
[not found] ` <1488400107.3610.1@smtp.autistici.org>
[not found] ` <2B251BF1-C965-444D-A831-9981861E453E@gmx.de>
[not found] ` <1488484262.16753.0@smtp.autistici.org>
2017-03-02 21:10 ` Dave Täht
2017-03-02 23:16 ` John Yates
2017-03-03 0:00 ` Jonathan Morton
2017-03-02 23:55 ` John Yates
2017-03-03 0:02 ` Jonathan Morton
2017-03-03 4:31 ` Eric Luehrsen
2017-03-03 4:35 ` Jonathan Morton
2017-03-03 5:00 ` Eric Luehrsen
2017-03-03 5:49 ` Jonathan Morton
2017-03-03 6:21 ` Dave Taht
2017-03-06 13:30 ` Benjamin Cronce
2017-03-06 14:44 ` Jonathan Morton
2017-03-06 18:08 ` Benjamin Cronce [this message]
2017-03-06 18:46 ` Jonathan Morton
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/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ_ENFF4jgjwo+1or8OMesH4j8UAHob9mOh+DEMP0X_a9+6GAw@mail.gmail.com \
--to=bcronce@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dave.taht@gmail.com \
--cc=ericluehrsen@hotmail.com \
/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