From: Russell King - ARM Linux <linux@arm.linux.org.uk> To: Joe Perches <joe@perches.com> Cc: Peter Korsgaard <jacmet@sunsite.dk>, Nicolas Pitre <nico@fluxnic.net>, "Markus F.X.J. Oberhumer" <markus@oberhumer.com>, Kyungsik Lee <kyungsik.lee@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Michal Marek <mmarek@suse.cz>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, x86@kernel.org, celinux-dev@lists.celinuxforum.org, Nitin Gupta <nitingupta910@gmail.com>, Richard Purdie <rpurdie@openedhand.com>, Josh Triplett <josh@joshtriplett.org>, Joe Millenbach <jmillenbach@gmail.com>, David Sterba <dsterba@suse.cz>, Richard Cochran <richardcochran@gmail.com>, Albin Tonnerre <albin.tonnerre@free-electrons.com>, Egon Alter <egon.alter@gmx.net>, hyojun.im@lge.com, chan.jeong@lge.com, raphael.andy.lee@gmail.com Subject: Re: [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel Date: Wed, 27 Feb 2013 17:36:44 +0000 [thread overview] Message-ID: <20130227173644.GC17833@n2100.arm.linux.org.uk> (raw) In-Reply-To: <1361984688.2035.20.camel@joe-AO722> 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: > > 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. ROTFL. > > I'm curious - what in your mind qualifies "significant value" ? > > faster boot time. smaller, faster overall code. 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" ! > > 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...) > > 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 I'm not looking in the right spot. 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: [ 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" to: .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 kernel messages. > > > Why would the LZO code not be updated? > > I'm not saying that the LZO code should not be updated. > > You said: > > > > > > > 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.
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel Date: Wed, 27 Feb 2013 17:36:44 +0000 [thread overview] Message-ID: <20130227173644.GC17833@n2100.arm.linux.org.uk> (raw) In-Reply-To: <1361984688.2035.20.camel@joe-AO722> 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: > > 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. ROTFL. > > I'm curious - what in your mind qualifies "significant value" ? > > faster boot time. smaller, faster overall code. 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" ! > > 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...) > > 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 I'm not looking in the right spot. 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: [ 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" to: .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 kernel messages. > > > Why would the LZO code not be updated? > > I'm not saying that the LZO code should not be updated. > > You said: > > > > > > > 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.
next prev parent reply other threads:[~2013-02-27 17:38 UTC|newest] Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-26 6:24 [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel Kyungsik Lee 2013-02-26 6:24 ` Kyungsik Lee 2013-02-26 6:24 ` [RFC PATCH v2 1/4] decompressor: Add LZ4 decompressor module Kyungsik Lee 2013-02-26 6:24 ` Kyungsik Lee 2013-02-26 13:12 ` David Sterba 2013-02-26 13:12 ` David Sterba 2013-02-27 4:38 ` Kyungsik Lee 2013-02-27 4:38 ` Kyungsik Lee 2013-02-26 6:24 ` [RFC PATCH v2 2/4] lib: Add support for LZ4-compressed kernel Kyungsik Lee 2013-02-26 6:24 ` Kyungsik Lee 2013-02-26 14:00 ` David Sterba 2013-02-26 14:00 ` David Sterba 2013-02-28 5:22 ` Kyungsik Lee 2013-02-28 5:22 ` Kyungsik Lee 2013-02-26 6:24 ` [RFC PATCH v2 3/4] arm: " Kyungsik Lee 2013-02-26 6:24 ` Kyungsik Lee 2013-02-26 6:24 ` [RFC PATCH v2 4/4] x86: " Kyungsik Lee 2013-02-26 6:24 ` Kyungsik Lee 2013-02-26 20:33 ` [RFC PATCH v2 0/4] " Markus F.X.J. Oberhumer 2013-02-26 20:33 ` Markus F.X.J. Oberhumer 2013-02-26 20:59 ` Nicolas Pitre 2013-02-26 20:59 ` Nicolas Pitre 2013-02-26 21:58 ` Peter Korsgaard 2013-02-26 21:58 ` Peter Korsgaard 2013-02-26 22:09 ` Nicolas Pitre 2013-02-26 22:09 ` Nicolas Pitre 2013-02-26 22:10 ` Russell King - ARM Linux 2013-02-26 22:10 ` Russell King - ARM Linux 2013-02-27 1:40 ` Joe Perches 2013-02-27 1:40 ` Joe Perches 2013-02-27 9:56 ` Russell King - ARM Linux 2013-02-27 9:56 ` Russell King - ARM Linux 2013-02-27 15:49 ` Joe Perches 2013-02-27 15:49 ` Joe Perches 2013-02-27 16:08 ` Nicolas Pitre 2013-02-27 16:08 ` Nicolas Pitre 2013-02-27 16:08 ` Nicolas Pitre 2013-02-27 16:31 ` Russell King - ARM Linux 2013-02-27 16:31 ` Russell King - ARM Linux 2013-02-27 16:53 ` Borislav Petkov 2013-02-27 16:53 ` Borislav Petkov 2013-02-27 17:04 ` Joe Perches 2013-02-27 17:04 ` Joe Perches 2013-02-27 17:16 ` Nicolas Pitre 2013-02-27 17:16 ` Nicolas Pitre 2013-02-27 17:39 ` Joe Perches 2013-02-27 17:39 ` Joe Perches 2013-02-27 17:52 ` Nicolas Pitre 2013-02-27 17:52 ` Nicolas Pitre 2013-02-27 17:57 ` Russell King - ARM Linux 2013-02-27 17:57 ` Russell King - ARM Linux 2013-02-27 17:36 ` Russell King - ARM Linux [this message] 2013-02-27 17:36 ` Russell King - ARM Linux 2013-02-28 4:22 ` Joe Perches 2013-02-28 4:22 ` Joe Perches 2013-02-27 7:36 ` Kyungsik Lee 2013-02-27 7:36 ` Kyungsik Lee 2013-02-27 9:51 ` Russell King - ARM Linux 2013-02-27 9:51 ` Russell King - ARM Linux 2013-02-27 10:20 ` Johannes Stezenbach 2013-02-27 10:20 ` Johannes Stezenbach 2013-02-27 15:35 ` Nicolas Pitre 2013-02-27 15:35 ` Nicolas Pitre 2013-02-27 13:23 ` Kyungsik Lee 2013-02-27 13:23 ` Kyungsik Lee 2013-02-27 22:21 ` Andrew Morton 2013-02-27 22:21 ` Andrew Morton
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130227173644.GC17833@n2100.arm.linux.org.uk \ --to=linux@arm.linux.org.uk \ --cc=akpm@linux-foundation.org \ --cc=albin.tonnerre@free-electrons.com \ --cc=celinux-dev@lists.celinuxforum.org \ --cc=chan.jeong@lge.com \ --cc=dsterba@suse.cz \ --cc=egon.alter@gmx.net \ --cc=hpa@zytor.com \ --cc=hyojun.im@lge.com \ --cc=jacmet@sunsite.dk \ --cc=jmillenbach@gmail.com \ --cc=joe@perches.com \ --cc=josh@joshtriplett.org \ --cc=kyungsik.lee@lge.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=markus@oberhumer.com \ --cc=mingo@redhat.com \ --cc=mmarek@suse.cz \ --cc=nico@fluxnic.net \ --cc=nitingupta910@gmail.com \ --cc=raphael.andy.lee@gmail.com \ --cc=richardcochran@gmail.com \ --cc=rpurdie@openedhand.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.