Bug#592519: initramfs-tools: COMPRESS option should be more flexible
On Fri, 2020-09-25 at 14:19 -0300, Rogério Brito wrote: > Package: initramfs-tools > Version: 0.139 > Followup-For: Bug #592519 > X-Debbugs-Cc: b...@debian.org, m...@debian.org, debian-kernel@lists.debian.org > > > Hi. > > In a similar vein to what was reported by Roger Shimizu, it takes ages to > compress with xz on an armel system with only 128MB of RAM. By default, > (which is what is used) xz uses level 6 compression and that is what takes a > lot of time to compress. > > I switched to gzip and the initrd is quite larger. I just performed some > tests with perf stat running 3 times a lot of commands to compress my > current initrd.img-5.8.0-1-marvell and I found xz -0 both to be faster than > gzip -9 *and* generating a smaller file as a result. [...] Try zstd? If you still feel you need this flexibility, I'm open to taking a patch that allows specifying the compression level *only*. I don't want to allow specifying arbitrary options. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Bug#592519: initramfs-tools: COMPRESS option should be more flexible
Package: initramfs-tools Version: 0.139 Followup-For: Bug #592519 X-Debbugs-Cc: b...@debian.org, m...@debian.org, debian-kernel@lists.debian.org Hi. In a similar vein to what was reported by Roger Shimizu, it takes ages to compress with xz on an armel system with only 128MB of RAM. By default, (which is what is used) xz uses level 6 compression and that is what takes a lot of time to compress. I switched to gzip and the initrd is quite larger. I just performed some tests with perf stat running 3 times a lot of commands to compress my current initrd.img-5.8.0-1-marvell and I found xz -0 both to be faster than gzip -9 *and* generating a smaller file as a result. Here are some results that I gathered. I didn't wait for xz with the default -6 level to finish... | compressor | time | size | |--++--| | gzip -9nk| 69.264 | 5980207 | | gzip -nk | 34.468 | 5995619 | | xz -0k | 35.280 | 5000752 | | xz -1k | 45.351 | 4868388 | | xz --check=crc32 -1k | 44.902 | 4868384 | | bzip2 -k | 51.750 | 5709152 | | uncompressed | 0 | 12965376 | Passing an option to xz (or, in general, to any compressor) would be, indeed, very nice. OTOH, on a fast machine, I would like to use something like xz -9e (that is, maximum compression---probably overkill for not so large files---but with "extreme" searches for more compression). Thanks, Rogério Brito. -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#592519: initramfs-tools: COMPRESS option should be more flexible
On Tue, 10 Aug 2010 21:27:56 +0400 sergio wrote: > Package: initramfs-tools > Version: 0.98 > Severity: wishlist > > Option COMPRESS shouldn't specify predefined compression method, but should set > program to use. This allows to use arguments (--best or --fast for example), > and other versions and implementation of compressors. > If initramfs-tools wants to know type of compression, one more option > (COMPRESS_TYPE for example) should be added. > > If initramfs-tools uses libraries (and doesn't call external program for > compression) may be all this is superfluous, but in this case should be > possible to specify compression level. Exactly this was the reason how I found the bug now. Instead of filing one. I changed compression type to lzop to make the update-initramfs call faster. But now I saw it gets run with -9 instead of -6 which is much faster on my notebook with i3. I don't care if the initramfs is 2 MiB bigger or smaller. But having it created faster would be nice. So any news on this old feature request? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1434628896.2891.3.ca...@z-51.de
Bug#592519: initramfs-tools: COMPRESS option should be more flexible
Package: initramfs-tools Version: 0.98 Severity: wishlist Option COMPRESS shouldn't specify predefined compression method, but should set program to use. This allows to use arguments (--best or --fast for example), and other versions and implementation of compressors. If initramfs-tools wants to know type of compression, one more option (COMPRESS_TYPE for example) should be added. If initramfs-tools uses libraries (and doesn't call external program for compression) may be all this is superfluous, but in this case should be possible to specify compression level. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 6.2M Aug 9 15:30 /boot/initrd.img-2.6.32-5-686 -rw-r--r-- 1 root root 6.2M Aug 9 15:32 /boot/initrd.img-2.6.32-5-amd64 -rw-r--r-- 1 root root 6.5M Jul 11 20:08 /boot/initrd.img-2.6.34-1-686 -rw-r--r-- 1 root root 6.4M Aug 9 15:34 /boot/initrd.img-2.6.34-1-amd64 -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-2.6.34-1-amd64 root=UUID=a2932eb6-f687-4334-9a86-f466c65232f8 ro acpi_enforce_resources=lax -- /proc/filesystems ext4 fuseblk ext2 ext3 reiserfs xfs jfs msdos vfat ntfs minix hfs hfsplus qnx4 ufs btrfs -- lsmod Module Size Used by pl2303 13744 0 usbserial 26927 1 pl2303 btrfs 381227 0 zlib_deflate 17762 1 btrfs crc32c 2568 1 libcrc32c 1050 1 btrfs ufs58627 0 qnx4 0 hfsplus65214 0 hfs37431 0 minix 21189 0 ntfs 163615 0 vfat7892 0 msdos 5922 0 fat40064 2 vfat,msdos jfs 139859 0 xfs 736330 0 exportfs3146 1 xfs reiserfs 194955 0 ext3 106534 0 jbd37413 1 ext3 ext2 53478 0 usbhid 33619 0 iptable_nat 3667 1 nf_nat 13588 1 iptable_nat nf_conntrack_ipv4 9697 3 iptable_nat,nf_nat nf_conntrack 47348 3 iptable_nat,nf_nat,nf_conntrack_ipv4 nf_defrag_ipv4 1211 1 nf_conntrack_ipv4 ip_tables 13874 1 iptable_nat x_tables 13185 2 iptable_nat,ip_tables aes_x86_64 7348 3 aes_generic25722 1 aes_x86_64 tun12120 2 radeon613330 2 ttm39677 1 radeon drm_kms_helper 19993 1 radeon drm 144452 5 radeon,ttm,drm_kms_helper i2c_algo_bit4265 1 radeon hidp 11336 1 hid63661 2 usbhid,hidp sco 7492 2 bridge 53396 0 stp 1448 1 bridge bnep9634 2 rfcomm 29951 8 l2cap 25527 21 hidp,bnep,rfcomm vboxnetadp 4193 0 vboxnetflt 12287 0 vboxdrv 1723566 2 vboxnetadp,vboxnetflt kvm_amd32438 0 kvm 223894 1 kvm_amd fuse 50206 1 powernow_k811018 1 it87 22007 0 hwmon_vid 1836 1 it87 loop 11686 0 dm_crypt 10704 0 dm_mod 54982 1 dm_crypt snd_hda_codec_atihdmi 2275 1 arc41282 2 snd_hda_codec_realtek 251256 1 ecb 1849 2 snd_hda_intel 19699 0 snd_hda_codec 64180 3 snd_hda_codec_atihdmi,snd_hda_codec_realtek,snd_hda_intel snd_hwdep 5244 1 snd_hda_codec snd_pcm61303 2 snd_hda_intel,snd_hda_codec snd_seq41567 0 snd_timer 15645 2 snd_pcm,snd_seq snd_seq_device 4501 1 snd_seq ath5k 115940 0 i2c_piix4 8384 0 snd46594 8 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq,snd_timer,snd_seq_device mac80211 149675 1 ath5k ath 8394 1 ath5k shpchp 25503 0 edac_core 29141 0 pcspkr 1707 0 pci_hotplug19931 1 shpchp button 4706 0 i2c_core 15406 5 radeon,drm_kms_helper,drm,i2c_algo_bit,i2c_piix4 processor 28793 1 powernow_k8 edac_mce_amd6513 0 soundcore 4742 1 snd btusb 9793 4 cfg80211 116306 3 ath5k,mac80211,ath led_class 2187 1 ath5k tpm_tis 7344 0 tpm 9533 1 tpm_tis snd_page_alloc 6273 2 snd_hda_intel,snd_pcm k8temp 3147 0 tpm_bios4497 1 tpm evdev 7432 9 blue