On 12.06.2022 21:58, Rafał Miłecki wrote:
6. Organizing kernel symbols
CPUs of home routers usually have small caches. The way kernel
symbols get organized during compilation may significantly affect
network performance [3]. It's especially annoying as network
unrelated changes
Il giorno ven 17 giu 2022 alle ore 13:51 Hauke Mehrtens
ha scritto:
>
> Hi Rafal,
>
> Thank you for your detailed analyses and also for the detailed report.
> This is very helpful when I ran into this problem.
>
> Can we somehow automate it so that we get notified a day after a bad
> change was
Hi Rafal,
Thank you for your detailed analyses and also for the detailed report.
This is very helpful when I ran into this problem.
Can we somehow automate it so that we get notified a day after a bad
change was committed about performance regression and not one year after?
On 6/14/22
[Ugh, now with less HTML, sorry about that…]
Hi, Rafał,
On Tue, 14 Jun 2022 at 14:20, Rafał Miłecki wrote:
>
> As you can see 4e0c54bc5bc8 has accidentally moved -fno-reorder-blocks
> from !CONFIG_CC_OPTIMIZE_FOR_SIZE to CONFIG_CC_OPTIMIZE_FOR_SIZE.
>
> I've noticed problem with
On 12.06.2022 21:58, Rafał Miłecki wrote:
5. 7125323b81d7 ("bcm53xx: switch to kernel 5.4")
Improved network speed by 25% (256 Mb/s → 320 Mb/s).
I didn't have time to bisect this *improvement* to a single kernel
commit. I tried profiling but it isn't obvious to me what caused that
improvement.
During last years NAT performance on Northstar (bcm53xx) changed
multiple times. Noone keeps a close eye on this and Northstar testing
results also seem very unstable. During last 2 months I probably tested
over a hundred of OpenWrt commits going back to 2015.
I decided to do testing with
Over years I saw multiple reports that new OpenWrt release / kernel
update / netifd change / DSA introduction caused a regression in router
network / NAT speed (masquerade NAT in most cases). Most of those
reports remained unresolved I believe.
The problem is that:
1. OpenWrt doesn't have
