![]() ![]() Since Arch Linux developers performed the comparison of different compression algorithmsIn the end they opted to plan to use zstd instead of the default compression algorithm in devtools. In this particular case, copying to memory is directly done by the emulator, and we just need CPU cycles to start the kernel.Arch Linux developers have released recently through a statement on your intention to enable support for compression algorithm zstd (included since November 2017 in Linux kernel 4.14) in the pacman package manager. This is the case of CPUs emulated on an FPGA (typically during chip development, before silicon is available). ![]() Using a kernel image without compression is rarely a worthy solution, except in systems with a very slow CPU.On systems with a fast CPU, like the Panda board, boot time with xz is actually pretty close to lzo, and therefore can be a very interesting compromise between kernel size and boot time.On systems with a fast CPU, and very slow storage though, xz should be the best solution Because of their heavy CPU usage, lzma and xz remain pretty bad in terms of boot time, on most types of storage devices.Therefore, there’s no reason to stick to lzma compression if you used it. xz is always better than lzma, both in terms of image size.Remember, lzo kernel compression was merged by Bootlin. lzo is still the best solution for minimum boot time.Here’s what we learned from these benchmarks: This case is a typical example of industrial systems (AT91SAM9263 is still very popular in such applications, as we can see from customer requests), booting from NAND storage operating with a 200 to 400 MHz CPU. Therefore, we expect both the kernel size and the decompression algorithm to have a major impact on boot time. In this case, we have a slow CPU with slow storage. Note that we are using the nboot command from U-boot, which guarantees that we just copy the number of bytes specified in the uImage header. ![]() Here we are booting from NAND flash, which is the fastest way to boot a kernel on this board. The USB-A9263 board from Calao Systems has a cheaper and much slower AT91SAM9263 CPU running at 200 MHz. Results on Calao Systems USB-A9263 (AT91) This case typically represents todays multimedia and mobile devices such as phones, media players and tablets. Therefore, the time taken to copy the kernel from storage to RAM is expected to have a significant impact on boot time. In this case, we have a fast CPU, but with rather slow storage. Unfortunately, the MMC/SD interface of the board is rather slow. ![]() The standard way to boot this board is from an MMC/SD card. The Panda board has a fast dual Cortex A9 CPU (OMAP 4430) running at 1 GHz. ~/bin/grabserial -v -d /dev/ttyUSB0 -e 15 -t -m "Uncompressing Linux" -i "done," > booting-lzo.log Compression time measured between “Uncompressing Linux” and “done”:.Loading time is measured between “reading uImage” and “OK” (right before “Starting kernel”) in the bootloader messages.Our benchmarks just measure the time for the bootloader to copy the kernel to RAM, and then the time taken by the kernel to uncompress itself. This allow to measure time from the earliest power on stages, and doesn’t slow down the target system by adding instrumentation to it. This utility reads messages coming out of the serial line, and adds timestamps to each line it receives. I used the very useful grabserial script from Tim Bird. I also used the U-boot bootloader in both cases. Benchmark methodologyįor both boards I tested, I used the same pre 3.3 Linux kernel from Linus Torvalds’ mainline git tree. As the decompressing code is the same, the results should be the same as if I had used the patches that are going upstream. It can be considered as the successor of lzma, and achieves even better compression ratios!īefore submitting my patches, I ran a few benchmarks on my own implementation. xz is a compression format based on the LZMA2 compression algorithm. The good news is that xz kernel compression support should be available in Linux 3.4 in a few months from now. I should have checked the mailing list archives too. The lesson I learned was that checking a git tree is not always sufficient. However, it was too late as Russell King, the ARM Linux maintainer, alreadyaccepted a similar patch, about 3 weeks before my submission. I recently managed to find time to clean up and submit my patches for xz kernel compression support on ARM, which I started working on back in November, during my flight to Linaro Connect. ![]()
0 Comments
Leave a Reply. |