Russell King - ARM Linux <linux@...> wrote: It sounds like we should merge both. I've sent Linus a little reminder for Markus's 3.9 pull request. Let's get down and review and test

Total claptrap. I've no idea where you're getting your data from, but it's franky wrong and you're now being totally misleading to anyone else reading this thread. I explicitly asked for a

Right. Can the new LZO code be merged by Linus now? It has been sitting in linux-next for quite some time. Afterwards we could revisit lz4 worthiness without all the present confusion. BTW, I

Yeah, I can see how that can be interpreted. I'm referring only to the new LZO. I guess Russell has not reviewed the new LZO. There is apparently no speed increase for LZ4 over the new LZO. I

ROTFL. ROTFL again! Because you've just disagreed with your above statement. "66% increase in decompression speed" as far as I know _is_ "faster boot time" ! While recently asking someone to enable

Sorry, but you certainly successfully got me confused, and probably others as well. RMK says that "66% increase in decompression speed over LZO" is significant. You apparently disagree with

We disagree. faster boot time. smaller, faster overall code. If you mean commit 0cc41e4a21d43, perhaps you could clarify with an example. I don't see any relevant changes by you in -next, but maybe

Hell yeah! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --

Sorry, a 66% increase in decompression speed over the updated LZO code isn't "significant value" ? I'm curious - what in your mind qualifies "significant value" ? Maybe "significant value" is a

Connecting to lkml.org (lkml.org)|87.253.128.182|:443... connected. HTTP request sent, awaiting response... 500 Server Error Please someone post a comprehensive comparison with all the results in

https://lkml.org/lkml/2013/1/29/145 I did not and do not see significant value in adding LZ4 given Markus' LZO improvements. I asked about LZO. Why would the LZO code not be updated? The new LZO

It is not about dropping LZO from the kernel entirely. It's about removing support for compressing zImage using LZO (and some others). There is no compatibility issue as zImage embeds its own

I have read the comments regarding how many compressors the kernel should support and understand that it can not support all the compressors available. However, I don't think that LZO can be replaced

I think LZO may be used by squashfs, jffs2 and btrfs, thus you cannot drop it without breaking on disk storage formats. Johannes

Please read the comments against the previous posting of these patches where I first stated this argument - and with agreement from those following the thread. The thread started on 26 Jan 2013.

That is pretty conclusive - it shows an 8% increase in image size vs a 66% increase in decompression speed. It will take a _lot_ to offset that increase in decompression speed. So, what I think is

I agree that the new LZO version provided shows better decompression speed than 3.7 based. It is much improved especially for UA. Compiler: Linaro ARM gcc 4.6.2 2. ARMv7, 1.7GHz based board

It's based on r88. Yes, Good point. It's about indent errors. The } is a pair of braces regarding "while (1) {". However it compiled. It will be fixed. Yes, right. It looks better if it's

How could it be questionable that it's worth updating the LZO code?

Well, until someone can put all the pieces together so that a reasonably meaningful test between: - The new LZO code - The new LZ4 code then you're all comparing different things. TBH, I'm