Re: [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel
Russell King - ARM Linux <linux@...>
On Wed, Feb 27, 2013 at 09:04:48AM -0800, Joe Perches wrote:
On Wed, 2013-02-27 at 16:31 +0000, Russell King - ARM Linux wrote:ROTFL.On Wed, Feb 27, 2013 at 07:49:12AM -0800, Joe Perches wrote:We disagree.On Wed, 2013-02-27 at 09:56 +0000, Russell King - ARM Linux wrote:Sorry, a 66% increase in decompression speed over the updated LZO codeOn Tue, Feb 26, 2013 at 05:40:34PM -0800, Joe Perches wrote:https://lkml.org/lkml/2013/1/29/145On Tue, 2013-02-26 at 22:10 +0000, Russell King - ARM Linux wrote:Please read the comments against the previous posting of these patchesSo... for a selected kernel version of a particular size, can we pleaseHow could it be questionable that it's worth updating the LZO code?
ROTFL again! Because you've just disagreed with your above statement.I'm curious - what in your mind qualifies "significant value" ?faster boot time. smaller, faster overall code.
"66% increase in decompression speed" as far as I know _is_ "faster
boot time" !
While recently asking someone to enable VFP debugging, so I could helpMaybe "significant value" is a patch which buggily involves convertingIf you mean commit 0cc41e4a21d43, perhaps you could clarify with an
sort out a problem they had reported, this is the debug output I was
greeted by thanks to your meddling:
[ 927.235546] \x01\x01\x01\x01\x01\x01\x01\x01
[ 927.241505] \x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01
Yes, really useful debug output isn't it? You can really see what's
going on there. These are coming from ultimately two commits - the
one you refer to above, which on its own would've changed the printk
string to be merely "<7>" - and the follow on commit changing the
way printk levels are dealt with.
The above output is produced by:
#define KERN_SOH "\001" /* ASCII Start Of Header */
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
.asciz KERN_DEBUG "VFP: \str\n"
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".
0000 01003700 5646503a 20696e73 74722025 ..7.VFP: instr %
0010 30387820 70632025 30387820 73746174 08x pc %08x stat
0020 65202570 0a000100 37005646 503a2066 e %p....7.VFP: f
That is: \x01 \x00 7 \x00 VFP: instr %08x pc %08x state %p \x00
See - three separately terminated strings because you changed:
.asciz "<7>VFP: \str\n"
.asciz "<7>" "VFP: \str\n"
which turned it into _two_ separately NUL-terminated strings, and then
the follow-on changes to printk kern levels changed this to:
.asciz "\001" "7" "VFP: \str\n"
producing _three_ separately NUL-terminated strings.
The commit is not in mainline, nor linux-next, but in my tree as of
yesterday (e36815e2e), ready to be pushed out when I've finished working
on fixing other problems with VFP - or when I decide to push it out ready
for submission during this merge window.
The change did enable reducing code size.??? Yea, right, meanwhile breaking the ability of stuff to produce
_In_ the decompressor. We're talking about the _decompressor_ inYou said:Why would the LZO code not be updated?I'm not saying that the LZO code should not be updated.Sounded as if you were doubtful to me.so that we can see whether it's worth updating the LZO code