From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DB60E3B2A4 for ; Mon, 11 Mar 2019 10:49:49 -0400 (EDT) Received: by mail-it1-x131.google.com with SMTP id z131so7661685itf.5 for ; Mon, 11 Mar 2019 07:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4nN10lXqcGNjDsy1WSchUqFugdfQx681OpumkYHpRUU=; b=GH0qnEM5NiATx/bKTf4fbrlkEI9EkzdfwCmSKwTxKBST175UnH5XPVfP67ufWnzcma aOQpO0jvI4Y1FyVxia6nTVH92rPbx+oFz6p7hMISpmYXjFH107H9Zuirhmv90YoTo9fB K1h2pWDmcwYNJp80NrM70cYBg6UaoeLLcGlZmo7Cs/YoJxrq9w536pSRpwlwzfeoFBco LfxHW3UDADTbqDu3nqncjiZEsg/I2jg+NW1A1uEnl7wS4uBWird3G37VpuB6MkjKfHJt YBKCBqJK0VKjFo8f6mlTX1TZj/QcqmT7cicSXJlBaV6Za0E6cGNL0aMyJSuxHKNJ8rqi c7ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4nN10lXqcGNjDsy1WSchUqFugdfQx681OpumkYHpRUU=; b=odZNGDWgjDAWqohdPqzMmjb8bFWLx5Z1bC4yx+VeNsLxfQrpv0YTNcF/U/6pUeN0HW WQcchU0MRTzt8sVhwMYtsICiccwQ04hYMk6QqCXtNCPPYPEWiNBqr4DQ3lmI2UgQ8+Wi 7E9mQBD6CGSkBNoKXhfFZDsYB6OKDYrhQIIeRA9Q0/cfrTWmZSJSbowcHK1RuKLlyI31 3vMu7cumHEyoipRC/L+LWXZ2n+OYr8GBZXn1ORtat/WUpgJoSTnJy9fRpVcDFqCTXF6u 2vkT1/j1CsJXvRvB0Ja0PKXH1g3q6wkzmCFa3+vWMlzB2wipYbcWUWJ6VPu4cPVBBxE3 NytA== X-Gm-Message-State: APjAAAVaj4pJRQLAi8bAZ6MiJqP71hyDOhmGKD2okrrWDtx/5ifqxt6O 5/xdVd4alKFGix6xSiVGzmRPWtksY4UOR/ZdB/Q= X-Google-Smtp-Source: APXvYqwnx2mZ1mBAAALLOapM3ZbCtZoO3wWexGE9i41vKvXQyzkgnkn4TbBUzKNcDtmQQpCcz1fFAos5lgsUtagKSs4= X-Received: by 2002:a24:f5c7:: with SMTP id k190mr31654ith.93.1552315789350; Mon, 11 Mar 2019 07:49:49 -0700 (PDT) MIME-Version: 1.0 References: <87wol83uio.fsf@toke.dk> In-Reply-To: <87wol83uio.fsf@toke.dk> From: Adrian Popescu Date: Mon, 11 Mar 2019 16:49:37 +0200 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Georgios Amanakis , Cake List Content-Type: multipart/alternative; boundary="000000000000341c6c0583d2af11" Subject: Re: [Cake] profiling using perf X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 14:49:50 -0000 --000000000000341c6c0583d2af11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, On Sat, Mar 9, 2019 at 6:03 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Georgios Amanakis writes: > > > Dear List, > > > > I made an effort to profile the performance of cake with perf in > > openwrt. perf was run on a WRT1900ACS router while downloading > > archlinux.iso via torrent in a LAN client. You can find the annotated > > sch_cake.c in the attachment as well as a performance histogram of > > sch_cake (percentages are relative to sch_cake). Hopefully people can > > take a look at it, and see if there are performance concerns. > > Hmm, nothing immediately jumps out as low-hanging fruit to be harvested. > It's not too surprising the 200+-line cake_dequeue() is where most time > is spent, since that is where the bulk of the algorithm is implemented. > > And, well, there's nothing in there that can obviously be removed unless > we want to drop features. I guess one could try to make it possible to > disable features at compile time; but that carries quite a bit of > complexity with it (for one, it needs testing with the combinatorial > explosion of possible configurations), so don't think it's realistic. > The only exception *might* be a compile time option to turn off those > stats that are not needed for the algorithm to run... > The algorithm itself has probably been optimized over the years. It might be a good idea to think of other ways to perform some operations and simplify the algorithm. The code may not be that slow on a high end CPU such as a Core i5 and anything faster. The problem with the current implementation is that it's not able to saturate a gigabit connection even on dual core ARM routers with frequencies above 1.2 GHz. Routers for home users are probably going to rely on hardware offloads to saturate gigabit connections for a long time. This doesn't mean cake is poorly optimized or poorly implemented. It's not a good fit for small embedded systems with small CPU caches. Different data structures might help improve performance. This is why I've run a bunch of tests over the last few weeks. My conclusion is that the current version of cake can't deal with more than 100 mbps on ar71xx. mt7621 seems to go up to about 200 mbps. I was thinking of a few things to try: - disable some stats and profile - lower the number of queues from 1024 to 256 - look into profiling to figure out what's causing cache misses - disable some features and profile again - set up a lab for all this testing It's hard to find the time to do all of this. There's a lot to learn in the process. > > -Toke > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --000000000000341c6c0583d2af11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,<= br>

On Sat, Mar 9, 2019 at 6:03 PM Toke H=C3=B8iland-J=C3=B8rgensen <toke@redhat.com> wrote:
Georgios Amanakis <gamanakis@gmail.com&g= t; writes:

> Dear List,
>
> I made an effort to profile the performance of cake with perf in
> openwrt. perf was run on a WRT1900ACS router while downloading
> archlinux.iso via torrent in a LAN client. You can find the annotated<= br> > sch_cake.c in the attachment as well as a performance histogram of
> sch_cake (percentages are relative to sch_cake). Hopefully people can<= br> > take a look at it, and see if there are performance concerns.

Hmm, nothing immediately jumps out as low-hanging fruit to be harvested. It's not too surprising the 200+-line cake_dequeue() is where most time=
is spent, since that is where the bulk of the algorithm is implemented.
=

And, well, there's nothing in there that can obviously be removed unles= s
we want to drop features. I guess one could try to make it possible to
disable features at compile time; but that carries quite a bit of
complexity with it (for one, it needs testing with the combinatorial
explosion of possible configurations), so don't think it's realisti= c.
The only exception *might* be a compile time option to turn off those
stats that are not needed for the algorithm to run...
=
The algorithm itself has probably been optimized over the years. = It
might be a good idea to think of other ways to perform some
operat= ions and simplify the algorithm. The code may not be that
slow on a high= end CPU such as a Core i5 and anything faster.

The problem with the= current implementation is that it's not able to
saturate a gigabit = connection even on dual core ARM routers with
frequencies above 1.2 GHz.= Routers for home users are probably going
to rely on hardware offloads = to saturate gigabit connections for a
long time. This doesn't mean c= ake is poorly optimized or poorly
implemented. It's not a good fit f= or small embedded systems with small
CPU caches.

Different data s= tructures might help improve performance.

This is why I've run a= bunch of tests over the last few weeks. My
conclusion is that the curre= nt version of cake can't deal with more
than 100 mbps on ar71xx. mt7= 621 seems to go up to about 200 mbps.

I was thinking of a few things= to try:
- disable some stats and profile
- lower the number of queue= s from 1024 to 256
- look into profiling to figure out what's causin= g cache misses
- disable some features and profile again
- set up a l= ab for all this testing

It's hard to find the time to do all of = this. There's a lot to learn
in the process.
=C2=A0

-Toke
_______________________________________________
Cake mailing list
Cake@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
--000000000000341c6c0583d2af11--