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

[Russell King - ARM Linux]

On Wed, Feb 27, 2013 at 09:39:47AM -0800, Joe Perches wrote:
> On Wed, 2013-02-27 at 12:16 -0500, Nicolas Pitre wrote:
> > On Wed, 27 Feb 2013, Joe Perches wrote:
> > > On Wed, 2013-02-27 at 16:31 +0000, Russell King - ARM Linux wrote:
> > > > 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" ?
> > > 
> > > We disagree.
> > > 
> > > > I'm curious - what in your mind qualifies "significant value" ?
> > > 
> > > faster boot time. smaller, faster overall code.
> > 
> > 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 that.
> 
> 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.

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 comparison of the _new_ LZO vs the LZ4 code,
and this is what I received from Kyungsik Lee in this thread:

	Compiler: Linaro ARM gcc 4.6.2
	2. ARMv7, 1.7GHz based board
	   Kernel: linux 3.7
	   Uncompressed Kernel Size: 14MB
	         Compressed Size  Decompression Speed
	    LZO  6.0MB            34.1MB/s            Old
	         ----------------------------------------
	         6.0MB            34.7MB/s            New
	         6.0MB            52.2MB/s(UA)
	    =============================================
	    LZ4  6.5MB            86.7MB/s
	UA: Unaligned memory Access support

And my statement of a "66% increase in speed" of LZ4 is comparing the
_new_ LZO code with unaligned access with the LZ4 code.

Now, you refer to Markus' results - but Markus' results do not say what
they're comparing - they don't say what the size of the compressed image
is, nor what the size of the uncompressed image was.

Now, Markus' results show a 42% increase in speed between the LZO-2012
and LZO-2013-UA versions (do the calculation yourself - I'm sure you're
capable of that?  If not, we can turn this into a maths lesson too).
The above shows a 53% increase in speed between the existing LZO code
and the new LZO code with unaligned accesses.

_But_ the above shows an additional 66% increase between the new LZO
code with unaligned accesses and LZ4.  Or, a whopping 150% increase
in speed over the _existing_ LZO code.

So please, stop stating what I have and have not reviewed.  Unlike you,
I _have_ been following everything that's been said in this thread, and
 - unlike you - I have analysed the figures put forward and drawn
conclusions which are fully supported by the published data from them,
and stated them - now many times.