Sven

Hello, I've got two questions for you folks: 1.) Why is LZO being used over LZO-RLE for /etc/default/armbian-zram-config? 2.) Are there any downsides or risks currently known from using the kernel option CONFIG_UACCESS_WITH_MEMCPY? To 1.) I've been looking at LZO-RLE, which is the improved version of the LZO algorithm, and since it was made part of the kernel a while ago was I expecting some form of kernel configuration option to enable it. It is however included by default when LZO was configured and one just needs to specify "lzo-rle" over "lzo" as algorithm for zramctl. This means one only needs to replace "lzo" with "lzo-rle" in /etc/default/armbian-zram-config to use it. Because it has been a part of the kernel since 5.1 am I wondering why this hasn't been made the default in Armbian. It could have been overlooked of course, but perhaps there is more to it, which is why I'm asking here. zramctl itself doesn't list "lzo-rle" as one of it's algorithms, but it appears to be working: # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram1 lzo-rle 246.1M 56.9M 3.5M 5.1M 4 [SWAP] In /usr/lib/armbian/armbian-zram-config, line 53, is "lzo" used as the default. To 2.) I'm running Armbian on an Allwinner H2 SBC and the kernel option CONFIG_UACCESS_WITH_MEMCPY gives a minor performance gain, but the option isn't enabled in the default kernel for this SBC. As a reminder, here the kernel help on this option: Implement faster copy_to_user and clear_user methods for CPU cores where a 8-word STM instruction give significantly higher memory write throughput than a sequence of individual 32bit stores. A possible side effect is a slight increase in scheduling latency between threads sharing the same address space if they invoke such copy operations with large buffers. However, if the CPU data cache is using a write-allocate mode, this option is unlikely to provide any performance gain. I've so far only seen gains, not very large, but still noticeable. One can see it when using "armbianmonitor -z", but also with dd. If anyone has experimented with this options, knows more about it, especially about it's risks and downsides then I'd appreciate it if you could drop a comment. Without the kernel option: # dd if=/dev/zero bs=16M count=1024 of=/dev/null 1024+0 records in 1024+0 records out 17179869184 bytes (17 GB, 16 GiB) copied, 9.73097 s, 1.8 GB/s With CONFIG_UACCESS_WITH_MEMCPY enabled: # dd if=/dev/zero bs=16M count=1024 of=/dev/null 1024+0 records in 1024+0 records out 17179869184 bytes (17 GB, 16 GiB) copied, 8.32831 s, 2.1 GB/s Cheers, Sven

Hello, not sure if I'm at the right place here, so please let me know if I'm wrong and where I need to be. Thanks in advance and my apologies... My problem is that for some time now does Apt keep deleting custom kernels in /boot and the package appears to delete kernels not only with a rough pattern, but with "-f" as well, ignoring any file permissions. I've been watching this for a while now and it has left me at first with unbootable devices until I've noticed the cause. I would very much appreciate it of the Armbian kernel package wouldn't just delete anything that looks remotely like a kernel from /boot with a "rm -f *", but only removes the files that have been part of a previously installed package and leaves all other files in place. An example: Preparing to unpack .../38-linux-image-current-sunxi_20.02.11_armhf.deb ... update-initramfs: Deleting /boot/initrd.img-5.6.3-sven1 <--- There again Removing obsolete file 5.4.30-sunxi Removing obsolete file uInitrd-5.6.3-sven1 <--- Not obsolete but actually a part of the running kernel Removing obsolete file uInitrd-5.4.30-sunxi update-initramfs: Deleting /boot/initrd.img-5.4.30-sunxi Unpacking linux-image-current-sunxi (20.02.11) over (20.02.9) ... I'd appreciate it if somebody could make this stop.