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.

I believe Markus has shown comparison testing in
this very thread.

https://patchwork.kernel.org/patch/2187441/

Then you say that faster boot time is significant.

Increasing speed in incumbent code without adding
defects is always useful no?. Replacing incumbent
code with new code should be debated for utility.

I still think there's not much value in adding LZ4.
LZ4 is not not faster than LZO, it's just more code.

On Wed, 27 Feb 2013, Joe Perches wrote:

On Wed, 2013-02-27 at 12:16 -0500, Nicolas Pitre wrote:

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.

I believe Markus has shown comparison testing in
this very thread.

https://patchwork.kernel.org/patch/2187441/

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 still wonder what that patch requiring ARM people approval is.


Nicolas

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.

On Wed, 27 Feb 2013 09:51:39 +0000
Russell King - ARM Linux <linux@...> wrote:

On Wed, Feb 27, 2013 at 04:36:47PM +0900, Kyungsik Lee wrote:

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

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 that yes, we should accept LZ4 and drop LZO from
the kernel - the "fast but may not be small" compression title has
clearly been taken by LZ4.

Akpm - what's your thoughts?

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 this new code?

David's review comments were useful.

I'd like to also see a Kconfig patch which makes x86 and arm kernels
default to the new LZ4 code. Then I can sneak that patch into
linux-next so the new code will get some testing. If we don't do that,
very few people will run it.

(removed Richard Purdie and Albin Tonnerre as their email addresses
seem to be bounding)

While recently asking someone to enable VFP debugging, so I could help
sort out a problem they had reported, this is the debug output I was
greeted by thanks to your meddling:

:) Meddling... You sound like one of those nameless
villains on Scooby Doo. If only I had a cool nickname
like Dave "Shaggy" Kliekamp. I guess you'd have to call
me Velma.

[ 927.235546] \x01\x01\x01\x01\x01\x01\x01\x01
...
[ 927.241505] \x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01

7.6 `.asciz "STRING"'...
========================

`.asciz' is just like `.ascii', but each string is followed by a zero
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
byte. The "z" in `.asciz' stands for "zero".
^^^^^

Yeah, sorry. I thought that the zero was after any
concatenation like .c. Learned something. 'preciate
that. Would have appreciated a polite "you broke it"
email too.

??? Yea, right, meanwhile breaking the ability of stuff to produce
kernel messages.

Fortunately, that's the only .S instance.

so that we can see whether it's worth updating the LZO code

Sounded as if you were doubtful to me.

_In_ the decompressor. We're talking about the _decompressor_ in
this thread.

My opinion is it's useful to update LZO.

cheers, Joe (aka: Velma)