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

Yes. However, it makes it more questionable to simply rip out compression methods without warning. Not that warnings help, as we have learned. -hpa

The fact that you are aware of it means we're not going to break them. But my point is that we must not be held back just in case someone out there might have painted himself in a corner without

I think they can be fairly flexible. Obviously gzip is always supported. I don't know the details. Well, it is too nasty for public confession, but it's called "paravirtualization". -hpa

Are you kidding? And what format do they expect? If people are doing weird things with formats we're about to remove then it's their fault if they didn't make upstream developers aware of it. And

Some utterly weird things like the Xen domain builder do that, because they have to. That is why we explicitly document that the payload is ELF and how to access it in the bzImage spec. -hpa

That would be hard to justify given that the kernel provides its own decompressor code, making the compression format transparent to bootloaders, etc. And no one should be poking into the

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

The only concern I have with that is if someone paints themselves into a corner and absolutely wants, say, LZO. Otherwise, per your list it pretty much sounds like we should have lz4, gzip, and

Ok. We already have: - lzma: 33% smaller than gzip, decompression speed between gzip and bzip2 - xz: 30% smaller than gzip, decompression speed similar to lzma - bzip2: 10% smaller than gzip,

Am Dienstag, 29. Januar 2013, 10:15:49 schrieb Russell King - ARM Linux: the problem gets more complicated as the "fastest" decompressor usually creates larger images which need more time to load

Well... when I saw this my immediate reaction was "oh no, yet another decompressor for the kernel". We have five of these things already. Do we really need a sixth? My feeling is that we should

In the embedded space, quick boot is a really important feature to have. Many people resort to awful hacks in order to improve boot time, and so I would welcome this option. I have seen arm systems

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@...> wrote: -- Sent from my

I'm guessing this is referring to commit 5010192d5a. Well, we used to have only one compressed format. Now we have nearly half a dozen, with the same worthiness issue between themselves. Either

Yes, exactly. If the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, then it is expected more boot-time improvement by LZ4-decompressor. Currently there are two architectures which support it