* Re: net: macb: fail when there's no PHY
[not found] ` <rqbobm$5qk$1@ciao.gmane.io>
@ 2020-12-04 8:28 ` Alexander Dahl
2020-12-04 17:36 ` Andrew Lunn
0 siblings, 1 reply; 2+ messages in thread
From: Alexander Dahl @ 2020-12-04 8:28 UTC (permalink / raw)
To: netdev; +Cc: Grant Edwards, linux-mtd, linux-arm-kernel
Hello Grant,
sorry if I just hijack your conversation, but I'm curious, because we are
using the same SoC. Adding linux-arm-kernel to Cc for the general performance
issues and linux-mtd for the ECC questions. O:-)
Am Donnerstag, 3. Dezember 2020, 23:20:38 CET schrieb Grant Edwards:
> On 2020-12-03, Andrew Lunn <andrew@lunn.ch> wrote:
> >> I don't think there's any way I could justify using a kernel that
> >> doesn't have long-term support.
> >
> > 5.10 is LTS. Well, it will be, once it is actually released!
>
> Convincing people to ship an unreleased kernel would be a whole
> 'nother bucket of worms.
+1
Judging just from the release dates of the last LTS kernels, I would have
guessed v5.11 will get LTS. But there has been no announcement yet and I
suppose there will be none before release? For ordinary users it's just like
staring in a crystal ball, so we aim at v5.4 for our more recent hardware
platforms. ¯\_(ツ)_/¯
>
> It's all moot now. The decision was just made to shelve the 5.4 kernel
> "upgrade" and stick with 2.6.33 for now.
>
> >> [It looks like we're going to have to abandon the effort to use
> >> 5.4. The performance is so bad compared to 2.6.33.7 that our product
> >> just plain won't work. We've already had remove features to the get
> >> 5.4 kernel down to a usable size, but we were prepared to live with
> >> that.]
> >
> > Ah. Small caches?
>
> Yep. It's An old Atmel ARM926T part (at91sam9g20) with 32KB I-cache
> and 32KB D-cache.
>
> A simple user-space multi-threaded TCP echo server benchmark showed a
> 30-50% (depending on number of parallel connections) drop in max
> throughput. Our typical applications also show a 15-25% increase in
> CPU usage for an equivalent workload. Another problem is high
> latencies with 5.4. A thread that is supposed to wake up every 1ms
> works reliably on 2.6.33, but is a long ways from working on 5.4.
We use the exact same SoC with kernel 4.9.220-rt143 (PREEMPT RT) currently,
after being stuck on 2.6.36.4 for quite a while. I did not notice significant
performance issues, but I have to admit, we never did extensive benchmarks on
network or CPU performance, because the workload also changed for that target.
However what gave us a lot less dropped packages was using the internal SRAM
as DMA buffer for RX packages received by macb. That did not make it in
mainline however, I did not put enough effort in polishing that patch back
when we migrated from 2.6 to 4.x. If you're curious, it's on GitHub:
https://github.com/LeSpocky/linux/tree/net-macb-sram-rx
> I asked on the arm kernel mailing list if this was typical/expected,
> but the post never made it past the moderator.
>
> > The OpenWRT guys make valid complaints that the code
> > hot path of the network stack is getting too big to fit in the cache
> > of small systems. So there is a lot of cache misses and performance is
> > not good. If i remember correctly, just having netfilter in the build
> > is bad, even if it is not used.
>
> We've already disabled absoltely everything we can and still have a
> working system. With the same features enabled, the 5.4 kernel was
> about 75% larger than a 2.6.33 kernel, so we had to trim quite a bit
> of meat to get it to boot on existing units.
Same here. v4.9 kernel image still fits, v4.14 is already too big for some
devices we delivered in the early days.
> We also can't get on-die ECC support for Micron NAND flash working
> with 5.4. Even it did work, we'd still have to add the ability to
> fall-back to SW ECC on read operations for the sake of backwards
> compatibility on units that were initially shipped without on-die ECC
> support enabled.
IIRC the SoC itself has issues with its ECC engine? See mainline
at91sam9g20ek_common.dtsi for example which sets nand-ecc-mode to "soft".
The SAM9G20 Errata chapter in the complete datasheet from 2015 (Atmel-6384F)
says two times in Section 44.1.3: "Perform the ECC computation by software."
Greets
Alex
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 2+ messages in thread