On Mon, Jan 28, 2013 at 11:29:14PM -0500, Nicolas Pitre wrote:
On Mon, 28 Jan 2013, Andrew Morton wrote:
On Sat, 26 Jan 2013 14:50:43 +0900I'm guessing this is referring to commit 5010192d5a.
Kyungsik Lee <kyungsik.lee@...> wrote:
This patchset is for supporting LZ4 compressed kernel and initial ramdisk onWhat's this "with enabled unaligned memory access" thing? You mean "if
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
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)
the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so,
that's only x86, which isn't really in the target market for this
It's a lot of code for a 50ms boot-time improvement. Does anyone haveWell, we used to have only one compressed format. Now we have nearly
any opinions on whether or not the benefits are worth the cost?
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.
This reminded me to check the status of the lzo update and it
seems it got lost?http://lkml.org/lkml/2012/10/3/144
(Cc: added, I hope Markus still cares and someone could
eventually take his patch once he resends it.)