Re: [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel


Russell King - ARM Linux <linux@...>
 

On Wed, Feb 27, 2013 at 07:49:12AM -0800, Joe Perches wrote:
On Wed, 2013-02-27 at 09:56 +0000, Russell King - ARM Linux wrote:
On Tue, Feb 26, 2013 at 05:40:34PM -0800, Joe Perches wrote:
On Tue, 2013-02-26 at 22:10 +0000, Russell King - ARM Linux wrote:
So... for a selected kernel version of a particular size, can we please
have a comparison between the new LZO code and this LZ4 code, so that
we can see whether it's worth updating the LZO code or replacing the
LZO code with LZ4?
How could it be questionable that it's worth updating the LZO code?
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. Thanks.
https://lkml.org/lkml/2013/1/29/145

I did not and do not see significant value in
adding LZ4 given Markus' LZO improvements.
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 patch which buggily involves converting
all those "<n>" printk format strings in assembly files to KERN_* macros,
thereby breaking those strings because you've not paid attention to what
.asciz means? (Yes, I've just cleaned that crap up after you...)

Why would the LZO code not be updated?
I'm not saying that the LZO code should not be updated. I'm saying that
the kernel boot time decompressor is not a play ground for an ever
increasing number of "my favourite compression method" crap. We don't
need four, five or even six compression methods there. We just need
three - a "fast but large", "small but slow" and "all round popular
medium".

Join Celinux-dev@lists.celinuxforum.org to automatically receive all group messages.