netdev - Re: net: macb: fail when there's no PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <rqbobm$5qk$1@ciao.gmane.io>
Date:   Thu, 3 Dec 2020 22:20:38 -0000 (UTC)
From:   Grant Edwards <grant.b.edwards@...il.com>
To:     netdev@...r.kernel.org
Subject: Re: net: macb: fail when there's no PHY

On 2020-12-03, Andrew Lunn <andrew@...n.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.

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.

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.

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.

--
Grant