Uhm... you're saying we have to be at one extreme or the other? We probably could drop the legacy lzma format, but someone might rely on it. Nicolas Pitre <nico@xxxxxxxxxxx> wrote: >On Mon, 28 Jan 2013, Andrew Morton wrote: > >> On Sat, 26 Jan 2013 14:50:43 +0900 >> Kyungsik Lee <kyungsik.lee@xxxxxxx> wrote: >> >> > This patchset is for supporting LZ4 compressed kernel and initial >ramdisk on >> > the x86 and ARM architectures. >> > >> > According to http://code.google.com/p/lz4/, LZ4 is a very fast >lossless >> > compression algorithm and also features an extremely fast decoder. >> > >> > Kernel Decompression APIs are based on implementation by Yann >Collet >> > (http://code.google.com/p/lz4/source/checkout). >> > De/compression Tools are also provided from the site above. >> > >> > The initial test result on ARM(v7) based board shows that the size >of kernel >> > with LZ4 compressed is 8% bigger than LZO compressed but the >decompressing >> > speed is faster(especially under the enabled unaligned memory >access). >> > >> > Test: 3.4 based kernel built with many modules >> > Uncompressed kernel size: 13MB >> > lzo: 6.3MB, 301ms >> > lz4: 6.8MB, 251ms(167ms, with enabled unaligned memory access) >> > >> > It seems that it___s worth trying LZ4 compressed kernel image or >ramdisk >> > for making the kernel boot more faster. >> > >> > ... >> > >> > 20 files changed, 663 insertions(+), 3 deletions(-) >> > >> > ... >> > >> >> What's this "with enabled unaligned memory access" thing? You mean >"if >> the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so, >> that's only x86, which isn't really in the target market for this >> patch, yes? > >I'm guessing this is referring to commit 5010192d5a. > >> It's a lot of code for a 50ms boot-time improvement. Does anyone >have >> any opinions on whether or not the benefits are worth the cost? > >Well, we used to have only one compressed format. Now we have nearly >half a dozen, with the same worthiness issue between themselves. >Either we keep it very simple, or we make it very flexible. The former > >would argue in favor of removing some of the existing formats, the >later >would let this new format in. > > >Nicolas -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
