From: jgarzik@pobox•com (Jeff Garzik)
To: linux-arm-kernel@lists•infradead.org
Subject: [GIT PULL] Update LZO compression
Date: Thu, 16 Aug 2012 11:21:49 -0400 [thread overview]
Message-ID: <502D100D.2030609@pobox.com> (raw)
In-Reply-To: <502C92C3.7090701@oberhumer.com>
On 08/16/2012 02:27 AM, Markus F.X.J. Oberhumer wrote:
> On 2012-08-15 16:45, Johannes Stezenbach wrote:
>> On Wed, Aug 15, 2012 at 02:02:43PM +0200, Markus F.X.J. Oberhumer wrote:
>>> On 2012-08-14 14:39, Johannes Stezenbach wrote:
>>>> On Tue, Aug 14, 2012 at 01:44:02AM +0200, Markus F.X.J. Oberhumer wrote:
>>>>> On 2012-07-16 20:30, Markus F.X.J. Oberhumer wrote:
>>>>>>
>>>>>> As stated in the README this version is significantly faster (typically more
>>>>>> than 2 times faster!) than the current version, has been thoroughly tested on
>>>>>> x86_64/i386/powerpc platforms and is intended to get included into the
>>>>>> official Linux 3.6 or 3.7 release.
>>>>>>
>>>>>> I encourage all compression users to test and benchmark this new version,
>>>>>> and I also would ask some official LZO maintainer to convert the updated
>>>>>> source files into a GIT commit and possibly push it to Linus or linux-next.
>>>>
>>>> Sorry for not reporting earlier, but I didn't have time to do real
>>>> benchmarks, just a quick test on ARM926EJ-S using barebox,
>>>> and found in the new version decompression is slower:
>>>> http://lists.infradead.org/pipermail/barebox/2012-July/008268.html
>>>
>>> I can only guess, but maybe your ARM cpu does not have an efficient
>>> implementation of {get,put}_unaligned().
>>
>> Yes, ARMv5 cannot do unaligned access. ARMv6+ could, but
>> I think the Linux kernel normally traps it for debug,
>> all ARM seem to use generic {get,put}_unaligned() implementation
>> which use byte access and shift.
>
> Hmm - I could imagine that we're wasting a lot of possible speed gain
> by not exploiting that feature on ARMv6+.
Or you could just realize that unaligned accesses are slow in the best
case, and are simply not supported on some processors.
If you think a little bit, I bet you could come up with a solution that
operates at cacheline-aligned granularity, something that would be _even
faster_ than simply fixing the code to do aligned accesses.
Jeff
next prev parent reply other threads:[~2012-08-16 15:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <50299142.2030504@oberhumer.com>
2012-08-14 12:39 ` [GIT PULL] Update LZO compression Johannes Stezenbach
2012-08-15 12:02 ` Markus F.X.J. Oberhumer
2012-08-15 14:45 ` Johannes Stezenbach
2012-08-16 6:27 ` Markus F.X.J. Oberhumer
2012-08-16 15:06 ` Johannes Stezenbach
2012-08-16 17:25 ` Roman Mamedov
2012-08-16 17:52 ` Andi Kleen
2012-08-16 18:18 ` Geert Uytterhoeven
2012-08-16 18:55 ` james northrup
2012-08-16 22:17 ` Andi Kleen
2012-08-17 1:23 ` Mitch Harder
2012-09-07 21:31 ` Andi Kleen
2012-08-16 15:21 ` Jeff Garzik [this message]
2012-08-16 16:20 ` Andi Kleen
2012-08-16 16:48 ` Jeff Garzik
2012-08-16 17:22 ` Johannes Stezenbach
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=502D100D.2030609@pobox.com \
--to=jgarzik@pobox$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox