Announcement

Collapse
No announcement yet.

Ubuntu/Debian Add LZ4-Compressed Initramfs Support, Will Auto Decide LZ4/XZ Choice

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ubuntu/Debian Add LZ4-Compressed Initramfs Support, Will Auto Decide LZ4/XZ Choice

    Phoronix: Ubuntu/Debian Add LZ4-Compressed Initramfs Support, Will Auto Decide LZ4/XZ Choice

    Back in March was the discussion about Ubuntu 18.10 considering an LZ4-compressed kernel image (initamfs) by default while now action has been taken on this support and coming up with a new default...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    i still havent figured which compression is best for SSD. probably the ones that are faster at cost of size?

    Comment


    • #3
      Originally posted by cj.wijtmans View Post
      i still havent figured which compression is best for SSD. probably the ones that are faster at cost of size?
      As said in the article: it depends on if you are size-constrained or not, and it will do the right thing automatically.

      Comment


      • #4
        Originally posted by tildearrow
        Typo: initamfs
        No, no, no. You didn't get it: initamfs = init is fs (similar to "I Am Robot")

        Comment


        • #5
          Originally posted by cj.wijtmans View Post
          i still havent figured which compression is best for SSD. probably the ones that are faster at cost of size?
          There is no one-size-fits-all approach. The more compressed something is, the harder your CPU+RAM have to work. So if you've got something like a Threadripper or i9 and a 5400RPM HDD, you'll get better performance by compressing the file as much as possible. Meanwhile, take that same compressed file and try to decompress it on a dual-core Pentium with an NVMe drive, it'll take significantly longer to decompress. Meanwhile, different compression methods take advantage of different CPU instructions. Some CPUs might not have all the instructions necessary, so they'll decompress much slower. For something like initramfs images, you need to take a middle-ground, since not everyone has a high-performance CISC CPU and not everyone has high-speed storage either, so you don't want the image to be too disproportionately bottlenecked.
          Last edited by schmidtbag; 23 August 2018, 01:12 PM.

          Comment


          • #6
            Originally posted by cj.wijtmans View Post
            i still havent figured which compression is best for SSD. probably the ones that are faster at cost of size?
            I'll add : it depends on the speed of the CPU and the speed of the SSD.

            But for SSDs: In your situation I would basically compare two compression aglos.
            - LZ4 : because it's the fastest decompression ever made. If your SSD is one of the latest NVMe and/or the CPU isn't that fast, as mentioned by schmidtbag, that would make sense as LZ4 nearly compresses at RAM-access speeds.
            - ZStd : (Once Facebook's patch are merged upstream) - it manages to both be a bit better than Gzip (only XZ is compressing better) while at the same time beating the crap out of it speed-wise (only LZ4 manages to be even faster). So as long as your storage isn't battery-powered RAM, it's a serious candidate.

            Beside the article's mention of space constraints (where XZ is still the king), as mentioned by schmidtbag,, XZ would also make sense on spinning rust and other media where the data comes at such a slow trickle, that you might as well spend the meantime at stronger (de-) compression to shorten load-times.

            For only once compressed then constantly decompressed data, like boot images (or like seldom accessed files on BTRFS) ZStd is even more interesting because it has a ton of aggressive compression profiles (including special different tables for smallish object, like an initramfs, or extremely small object like 128k blocks - which by coincidence is the amount of data BTRFS puts in a single compressed block for random access). You can spend some time once while creating the boot images (or while btrfs fi defragging, once that patch gets merged upstream), and gain speed thanks to even smaller amount of data to copy over.

            Comment


            • #7
              I don't get it. Why LZ4? To me it sounds like a wasted opportunity.
              At the initramfs point the kernel is fully initialized and ready to mount a root point. Why not parallelize the decompression?
              I'd much rather have a smaller initramfs than a bunch of idle cores twiddling their thumbs.
              What happened to utilizing the machine more efficiently?

              Comment


              • #8
                Is the first distribution to try this kind of compression? In general other distributions like Fedora, openSUSE etc. what kind of compression do they use?

                Comment


                • #9
                  Originally posted by milkylainen View Post
                  At the initramfs point the kernel is fully initialized and ready to mount a root point.
                  The initial ramfs is decompressed by the bootloader (e.g GRUB) and placed in memory along with the kernel before booting it. Parallelization would be nice but bootloaders generally like to keep things simple.

                  Comment


                  • #10
                    Back in March was the discussion about Ubuntu 18.10 considering an LZ4-compressed kernel image (initamfs) by default while now action has been taken on this support and coming up with a new default.
                    Err.. kernel image != initramfs.

                    Comment

                    Working...
                    X