Hi, Nicolas> To be fair, you should also take into account the compressed Nicolas> size of a typical ARM kernel. Sometimes a slightly slower Nicolas> decompressor may be faster overall if the

To be fair, you should also take into account the compressed size of a typical ARM kernel. Sometimes a slightly slower decompressor may be faster overall if the compressed image to work on is

Did you actually *try* the new LZO version and the patch (which is attached once again) as explained in https://lkml.org/lkml/2013/2/3/367 ? Because the new LZO version is faster than LZ4 in my

Can you please add a sentence what lz4 actually is before you start comparing it with the current competitor(s)? Please use a less cryptic way of representing a value of 8 MB. Also, this is a

What SVN version did you use? For safety reasons I suggest to add a temporary variable to avoid double evaluation of isize. Does this compile? The } is an extra one, and does not match the original

This patch integrates the LZ4 decompression code to the x86 pre-boot code. And it depends on two patchs below lib: Add support for LZ4-compressed kernel decompressor: Add LZ4 decompressor

This patch integrates the LZ4 decompression code to the arm pre-boot code. And it depends on two patchs below lib: Add support for LZ4-compressed kernel decompressor: Add LZ4 decompressor

This patch adds support for extracting LZ4-compressed kernel images, as well as LZ4-compressed ramdisk images in the kernel boot process. This depends on the patch below decompressor: Add LZ4

This patch adds support for LZ4 decompression in the Linux Kernel. LZ4 Decompression APIs for kernel are based on LZ4 implementation by Yann Collet. LZ4 homepage :

Hi, First of all, Thank you for the comments and emails from the community. Here is the second version of support for LZ4-compressed kernel. In this version, lz4_decompress() has been added. In case

I still can't find a link from the Linux Foundation's CELF website to where I should submit my talk outline. I emailed it to you, but it's still not

Hi, Please be reminded that the next Japan Jamboree is scheduled on March 8th (Japan Time). http://elinux.org/Japan_Technical_Jamboree_44 If you would like to make presentation remotely, we have

Hi everyone, Embedded Linux Conference is just around the corner - February 20-22 in San Francisco. We're very excited about our technical content again this year. We've got keynotes by

My feeling is that in this case it is unneccessarily hard for an outside contributor to get a patch accepted, all because get_maintainer.pl doesn't put someone in charge. Apparently it doesn't work

Hi, The next Japan Technical Jamboree (#44) is scheduled on March 8th, Friday. It is just 1 month to the date! Please block your schedule! http://elinux.org/Japan_Technical_Jamboree_44 Best, S.

I assume this code is sitting in *your* tree? How do you think it gets into mainline? There is no automatic way that code from linux-next gets merged into mainline. That is up to the tree owner to

The proposed LZO update currently lives in the linux-next tree. I had tried several times during the last 12 months to provide an update of the kernel LZO version, but community interest seemed low

In fact you can easily improve LZO decompression speed on armv7 by almost 50% by adding just a few lines for enabling unaligend access: armv7 (Cortex-A9), Linaro gcc-4.6 -O3, Silesia test corpus, 256

Yes, the larger image could matter. Definitely it takes longer. Here are some updated test cases: Including "loading time" lzo lz4 loading time:

I didn't test with the proposed LZO update you mentioned. Sorry, which one do you mean? I did some tests with the latest LZO in the mainline. As a result, LZO is not faster in an unaligned access