1. 09 8月, 2014 1 次提交
    • Y
      initramfs: support initramfs that is bigger than 2GiB · d97b07c5
      Yinghai Lu 提交于
      Now with 64bit bzImage and kexec tools, we support ramdisk that size is
      bigger than 2g, as we could put it above 4G.
      
      Found compressed initramfs image could not be decompressed properly.  It
      turns out that image length is int during decompress detection, and it
      will become < 0 when length is more than 2G.  Furthermore, during
      decompressing len as int is used for inbuf count, that has problem too.
      
      Change len to long, that should be ok as on 32 bit platform long is
      32bits.
      
      Tested with following compressed initramfs image as root with kexec.
      	gzip, bzip2, xz, lzma, lzop, lz4.
      run time for populate_rootfs():
         size        name       Nehalem-EX  Westmere-EX  Ivybridge-EX
       9034400256 root_img     :   26s           24s          30s
       3561095057 root_img.lz4 :   28s           27s          27s
       3459554629 root_img.lzo :   29s           29s          28s
       3219399480 root_img.gz  :   64s           62s          49s
       2251594592 root_img.xz  :  262s          260s         183s
       2226366598 root_img.lzma:  386s          376s         277s
       2901482513 root_img.bz2 :  635s          599s
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Rashika Kheria <rashika.kheria@gmail.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Kyungsik Lee <kyungsik.lee@lge.com>
      Cc: P J P <ppandit@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Cc: "Daniel M. Weeks" <dan@danweeks.net>
      Cc: Alexandre Courbot <acourbot@nvidia.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d97b07c5
  2. 21 2月, 2013 1 次提交
  3. 13 1月, 2012 1 次提交
  4. 14 1月, 2011 5 次提交
  5. 25 4月, 2010 1 次提交
  6. 12 1月, 2010 1 次提交
    • A
      lib: add support for LZO-compressed kernels · 7dd65feb
      Albin Tonnerre 提交于
      This patch series adds generic support for creating and extracting
      LZO-compressed kernel images, as well as support for using such images on
      the x86 and ARM architectures, and support for creating and using
      LZO-compressed initrd and initramfs images.
      
      Russell King said:
      
      : Testing on a Cortex A9 model:
      : - lzo decompressor is 65% of the time gzip takes to decompress a kernel
      : - lzo kernel is 9% larger than a gzip kernel
      :
      : which I'm happy to say confirms your figures when comparing the two.
      :
      : However, when comparing your new gzip code to the old gzip code:
      : - new is 99% of the size of the old code
      : - new takes 42% of the time to decompress than the old code
      :
      : What this means is that for a proper comparison, the results get even better:
      : - lzo is 7.5% larger than the old gzip'd kernel image
      : - lzo takes 28% of the time that the old gzip code took
      :
      : So the expense seems definitely worth the effort.  The only reason I
      : can think of ever using gzip would be if you needed the additional
      : compression (eg, because you have limited flash to store the image.)
      :
      : I would argue that the default for ARM should therefore be LZO.
      
      This patch:
      
      The lzo compressor is worse than gzip at compression, but faster at
      extraction.  Here are some figures for an ARM board I'm working on:
      
      Uncompressed size: 3.24Mo
      gzip  1.61Mo 0.72s
      lzo   1.75Mo 0.48s
      
      So for a compression ratio that is still relatively close to gzip, it's
      much faster to extract, at least in that case.
      
      This part contains:
       - Makefile routine to support lzo compression
       - Fixes to the existing lzo compressor so that it can be used in
         compressed kernels
       - wrapper around the existing lzo1x_decompress, as it only extracts one
         block at a time, while we need to extract a whole file here
       - config dialog for kernel compression
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: cleanup]
      Signed-off-by: NAlbin Tonnerre <albin.tonnerre@free-electrons.com>
      Tested-by: NWu Zhangjin <wuzhangjin@gmail.com>
      Acked-by: N"H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Tested-by: NRussell King <rmk@arm.linux.org.uk>
      Acked-by: NRussell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7dd65feb
新手
引导
客服 返回
顶部