vmspike

I'm not sure it's related to your issue, but on some pi's I've seen Ethernet bandwidth issues accumulating over uptime. It was related to only to a part of specific hardware models, so suspect might be related to either hardware or kernel/driver version/implementation. After some tests I've found that the issue affects only per TCP connection downlink bandwidth - UDP does not have limits, as well as uplink TCP, multiple downlink TCP connections bandwidth stacks linearly. The worst bw case I've seen is ~2Mbps per TCP conn. Reboot fixes the issue for a random time (briefly from a few hours to a few months). Sometimes(?) the issue disappears on its own. So far I've not found a fault-proof fix except a reboot, but changing tcp congestion algo is worth to try: # sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = reno bic cubic westwood highspeed hybla htcp vegas nv veno scalable lp yeah illinois bbr # sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_congestion_control = cubic # sysctl net.ipv4.tcp_congestion_control=bbr net.ipv4.tcp_congestion_control = bbr For tests you may use iperf3 varying -C/-P/-R/..., e.g.: # iperf3 -4 -f m -P 1 -i 0 -t 5 -c IPERF3_SRV_IP --bind LAN_IP -R -b 100M -u # Single connection DL UDP up to 100Mbps for 5 sec # iperf3 -4 -f m -P 1 -i 0 -c IPERF3_SRV_IP --bind LAN_IP -R -C bbr # Single TCP conn DL using BBR as a congestion algo ... # iperf3 -4 -f m -P 50 -i 0 -c IPERF3_SRV_IP --bind LAN_IP -R # 50 TCP conns DL

The same case was already discussed here, but with no result: Finally found that adding `swiotlb=1` to kernel args releases 64 MB of memory: /boot/armbianEnv.txt:extraargs=... nokaslr cma=0 swiotlb=0 but not disables it completely: [ 0.000000] software IO TLB: SWIOTLB bounce buffer size roundup to 1MB Now: MemTotal: 487684 kB Alternative option `iommu=off` does not work. So it's not for graphics. This option looks reasonable for less than 4 GB RAM devices(?) If someone knows potential drawbacks, please disclose.

Is it a way to reduce the amount of reserved memory on sunxi64 devices? Trying to remove all useless for my case features (video/audio/wireless) to free up memory/resources for other tasks. The amount of total (413M) vs real (512M) memory is quite low: # grep -e Mem -e Cma /proc/meminfo MemTotal: 422416 kB MemFree: 49620 kB MemAvailable: 314396 kB CmaTotal: 0 kB CmaFree: 0 kB # dmesg | grep Memory: [ 0.000000] Memory: 407924K/524288K available (14144K kernel code, 1456K rwdata, 8700K rodata, 3072K init, 521K bss, 116364K reserved, 0K cma-reserved) # grep extraargs /boot/armbianEnv.txt extraargs=cma=0 sunxi_no_mali_mem_reserve sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 # uname -a Linux pi160 6.6.65-current-sunxi64 #1 SMP Wed Dec 11 19:13:43 +04 2024 aarch64 GNU/Linux The tricks which works for `sunxi` (e.g. `orangepizero`) does not work for `sunxi64` boards: https://linux-sunxi.org/Kernel_arguments Attempt to specify that extraargs in /boot/armbianEnv.txt have no effect (also their defaults are absent in /boot/boot.cmd, while present in orangepizero's version), except for `cma=0` with is not directly related to total available memory. Custom kernel with `CONFIG_CMA=n` also changes nothing.