Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: "Björn Grönvall" <bjorngx@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] and the bad cpu news on arm is
Date: Sun, 20 Dec 2015 09:55:14 +0100	[thread overview]
Message-ID: <A1082344-FD2F-4BAC-87F6-5E9DA845DFD6@gmail.com> (raw)
In-Reply-To: <CAA93jw53DAF2jUGwCnGbqz=X0bu_OyW-uJsBFbbE_7iRYA7n2A@mail.gmail.com>

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

Hi Dave,

The data cache on the wndr3800 and the archer is only 32k bytes. Some arm models also have a small cache.

Since the cake data structures are comparatively large it is important to only bring data into the cache that will actually make a difference when enqueueing.

The attached patch avoids reading data that will not be used. It will also save instructions when there are “q->way_hits”.

N.B. If your arm has a large data cache this change may not make much of a difference.

Cheers,
/b


[-- Attachment #2: sch_cake.c.diff --]
[-- Type: application/octet-stream, Size: 1847 bytes --]

diff --git a/sch_cake.c b/sch_cake.c
index 2d03d5a..ac4cb83 100644
--- a/sch_cake.c
+++ b/sch_cake.c
@@ -329,42 +329,38 @@ cake_hash(struct cake_tin_data *q, const struct sk_buff *skb, int flow_mode)
 	} else {
 		u32 inner_hash = reduced_hash % CAKE_SET_WAYS;
 		u32 outer_hash = reduced_hash - inner_hash;
-		u32 i, j, k;
+		u32 i, k;
 
 		/* check if any active queue in the set is reserved for
-		 * this flow. count the empty queues in the set, too
+		 * this flow.
 		 */
 
-		for (i = j = 0, k = inner_hash; i < CAKE_SET_WAYS;
+		for (i = 0, k = inner_hash; i < CAKE_SET_WAYS;
 		     i++, k = (k + 1) % CAKE_SET_WAYS) {
 			if (q->tags[outer_hash + k] == flow_hash) {
 				q->way_hits++;
 				goto found;
-			} else if (list_empty(&q->flows[outer_hash + k].
-					      flowchain)) {
-				j++;
 			}
 		}
 
-		/* no queue is reserved for this flow */
-		if (j) {
-			/* there's at least one empty queue, so find one
-			 * to reserve.
-			 */
-			q->way_misses++;
-
-			for (i = 0; i < CAKE_SET_WAYS; i++, k = (k + 1)
-				     % CAKE_SET_WAYS)
-				if (list_empty(&q->flows[outer_hash + k].
-					       flowchain))
-					goto found;
-		} else {
-			/* With no empty queues default to the original
-			 * queue and accept the collision.
-			 */
-			q->way_collisions++;
+		/* no queue is reserved for this flow. find an empty
+		 * queue to reserve.
+		 */
+		for (i = 0, k = inner_hash; i < CAKE_SET_WAYS;
+		     i++, k = (k + 1) % CAKE_SET_WAYS) {
+			if (list_empty(&q->flows[outer_hash + k].
+					      flowchain)) {
+				q->way_misses++;
+				goto found;
+			}
 		}
 
+		/* With no empty queues default to the original
+		 * queue and accept the collision.
+		 */
+		k = inner_hash;	 /* evict this entry. */
+		q->way_collisions++;
+
 found:
 		/* reserve queue for future packets in same flow */
 		reduced_hash = outer_hash + k;

[-- Attachment #3: Type: text/plain, Size: 2154 bytes --]




On 19 Dec 2015, at 21:03, Dave Taht <dave.taht@gmail.com> wrote:

> is that bcake configured via sqm to do 200mbit/20mbit, rings
> in at 82% idle over a 2 minute period over a 1 minute rrul test.
> cake, in all it's glory of statistics, extra features, bells, and whistles...
> 
> is also 82% idle.
> 
> vs sqm's htb + fq_codel at 86% idle.
> 
> (in other words, this is not a direct measurement of the code under
> 'load' but over a large sampling interval comparing idle with the
> loaded state, AND (sigh) htb + fq_codel uses less cpu. am using the
> mpstat 1 120 test for this from the openwrt sysstat package)
> 
> The good news from my perspective:
> 
> A) that it works at all with linux 4.4rc4 on the linksys 1200ac, which
> was certainly not the case til last week
> B) We CAN profile now
> C) All systems for bandwidth (htb and cake) are accurate to 200mbit at
> least, on this hardware
> 
> The bad news from my perspective:
> 
> A) I ran out of time for this back in august. Really have a ton of
> wifi work stacked up.
> 
> B) I'd like to see someone show an instance where cake uses less cpu
> or is better in any way than htb+ fq_codel.
> 
> There is a very small latency improvement (.8ms vs 1ms on this path).
> 
> I do not see any other appreciable difference in cpu usage or network
> behavior... aside from negative ones.
> 
> Someone that's saying "ooh cake's better" *please* go measure rrul_be
> while running "mpstat 1 120" for both sqm with fq_codel and sqm with
> cake.
> 
> C) I will try to summon the energy to try it on mips myself, tomorrow.
> 
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


--

Björn Grönvall, bjorngx@gmail.com, Cell +46 70 768 06 35, Jabber/XMPP: bg@kth.se

“The ultimate tragedy is not the oppression and cruelty by the bad people but the silence over that by the good people.”

― Martin Luther King Jr.



  reply	other threads:[~2015-12-20  8:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-19 20:03 Dave Taht
2015-12-20  8:55 ` Björn Grönvall [this message]
2015-12-20 12:59   ` Dave Taht
2015-12-22  0:30     ` Jonathan Morton
2015-12-22  4:42     ` Jonathan Morton
2015-12-22  0:31   ` 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=A1082344-FD2F-4BAC-87F6-5E9DA845DFD6@gmail.com \
    --to=bjorngx@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=dave.taht@gmail.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