Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Support For Compressing The Linux Kernel With LZ4

  1. #1
    Join Date
    Jan 2007
    Posts
    14,780

    Default Support For Compressing The Linux Kernel With LZ4

    Phoronix: Support For Compressing The Linux Kernel With LZ4

    A set of patches that allow the Linux kernel image to be compressed with the LZ4 lossless compression algorithm have been published. The size of LZ4-compressed Linux kernel images are larger than using LZO compression, but there's promise that the boot times could be better...

    http://www.phoronix.com/vr.php?view=MTI4NjM

  2. #2
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,889

    Default

    Quote Originally Posted by BO$$ View Post
    What is the point of having a compressed kernel? Faster loading times from the HDD?
    Smaller footprint which means: yes faster loading times from hdd, smaller filesize ON the hdd (embedded) and means it can be shoved into RAM if you wanted the entire live system into ram for responsiveness

  3. #3
    Join Date
    Oct 2010
    Posts
    91

    Default

    what happened to btrfs's lz4 compression support?

    it seems lz4 makes sense a lot for always compressing files when not using a sandforce ssd.

  4. #4
    Join Date
    Sep 2011
    Posts
    688

    Default

    I wonder what would happen if a lossy algorythem was used

  5. #5
    Join Date
    Mar 2008
    Posts
    208

    Default

    Quote Originally Posted by AJenbo View Post
    I wonder what would happen if a lossy algorythem was used
    then you have a lossy system.

  6. #6
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,889

    Default

    Quote Originally Posted by AJenbo View Post
    I wonder what would happen if a lossy algorythem was used
    Then i'd hope that the decompression algorithm was very good about reconstructing the lost data which would probably mean a longer decompression time =P

  7. #7
    Join Date
    Apr 2011
    Posts
    35

    Default

    come on... 100ms difference, you cannot even measure that with your watch. But you can measure the init-time after the kernel is loaded...

  8. #8
    Join Date
    Jan 2007
    Posts
    418

    Default

    Quote Originally Posted by Ericg View Post
    Smaller footprint which means: yes faster loading times from hdd, smaller filesize ON the hdd (embedded) and means it can be shoved into RAM if you wanted the entire live system into ram for responsiveness
    I don't think you can have a running kernel, compressed in ram. As far as I know, it gets loaded from some form of storage (flash, hdd, nfs) and decompressed into ram.

    come on... 100ms difference, you cannot even measure that with your watch. But you can measure the init-time after the kernel is loaded...
    This was on their test-system I'm sure. I bet on an ARM-m3 it takes quite a lot longer. So we're talking about 100% faster decompression times (150ms vs 300ms).

  9. #9
    Join Date
    Dec 2012
    Posts
    196

    Default

    I guess Google is also very interested on this getting into mainline kernel.

  10. #10

    Default

    Quote Originally Posted by mercutio View Post
    what happened to btrfs's lz4 compression support?

    it seems lz4 makes sense a lot for always compressing files when not using a sandforce ssd.
    Perhaps you are thinking of ZFS. ZFSOnLinux HEAD has LZ4 support. I believe that btrfs had planned to adopt snappy. The two compression algorithms are roughly equivalent in benchmarks.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •