From: Johannes Stezenbach <js@sig21.net>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Andi Kleen <andi@firstfloor.org>,
"Markus F.X.J. Oberhumer" <markus@oberhumer.com>,
linux-kernel@vger.kernel.org, chris.mason@fusionio.com,
linux-btrfs@vger.kernel.org, Nitin Gupta <ngupta@vflare.org>,
Richard Purdie <rpurdie@openedhand.com>,
richard -rw- weinberger <richard.weinberger@gmail.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [GIT PULL] Update LZO compression
Date: Thu, 16 Aug 2012 19:22:51 +0200 [thread overview]
Message-ID: <20120816172251.GA25640@sig21.net> (raw)
In-Reply-To: <502D2471.407@pobox.com>
On Thu, Aug 16, 2012 at 12:48:49PM -0400, Jeff Garzik wrote:
> On 08/16/2012 12:20 PM, Andi Kleen wrote:
> >>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.
> >
> >Cache aligned compression is unlikely to compress anything at all.
> >Compression algorithms are usually by definition unaligned.
>
> Sure it's a bitstream, but that does not imply the impossibility of
> reading data in in an word-aligned manner.
>
> Maybe cache-aligned is ambitious, because of resultant code bloat,
> but machine-int-aligned is doable and reasonable.
Well, I for one would be content if the old and new lzo versions
could be merged based on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
(Assuming that the slowdown on ARM is due to unaligned access,
since the old version also uses get/put_unaligned, is the new
version actually using more unaligned accesses?)
Johannes
WARNING: multiple messages have this Message-ID (diff)
From: js@sig21.net (Johannes Stezenbach)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] Update LZO compression
Date: Thu, 16 Aug 2012 19:22:51 +0200 [thread overview]
Message-ID: <20120816172251.GA25640@sig21.net> (raw)
In-Reply-To: <502D2471.407@pobox.com>
On Thu, Aug 16, 2012 at 12:48:49PM -0400, Jeff Garzik wrote:
> On 08/16/2012 12:20 PM, Andi Kleen wrote:
> >>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.
> >
> >Cache aligned compression is unlikely to compress anything at all.
> >Compression algorithms are usually by definition unaligned.
>
> Sure it's a bitstream, but that does not imply the impossibility of
> reading data in in an word-aligned manner.
>
> Maybe cache-aligned is ambitious, because of resultant code bloat,
> but machine-int-aligned is doable and reasonable.
Well, I for one would be content if the old and new lzo versions
could be merged based on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
(Assuming that the slowdown on ARM is due to unaligned access,
since the old version also uses get/put_unaligned, is the new
version actually using more unaligned accesses?)
Johannes
next prev parent reply other threads:[~2012-08-16 17:23 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-13 23:44 [GIT PULL] Update LZO compression Markus F.X.J. Oberhumer
2012-08-14 3:15 ` Andi Kleen
2012-08-14 10:10 ` Markus F.X.J. Oberhumer
2012-08-14 12:39 ` Johannes Stezenbach
2012-08-14 12:39 ` Johannes Stezenbach
2012-08-15 12:02 ` Markus F.X.J. Oberhumer
2012-08-15 12:02 ` Markus F.X.J. Oberhumer
2012-08-15 14:45 ` Johannes Stezenbach
2012-08-15 14:45 ` Johannes Stezenbach
2012-08-16 6:27 ` Markus F.X.J. Oberhumer
2012-08-16 6:27 ` Markus F.X.J. Oberhumer
2012-08-16 15:06 ` Johannes Stezenbach
2012-08-16 15:06 ` Johannes Stezenbach
2012-08-16 17:25 ` Roman Mamedov
2012-08-16 17:25 ` Roman Mamedov
2012-08-16 17:52 ` Andi Kleen
2012-08-16 17:52 ` Andi Kleen
2012-08-16 18:18 ` Geert Uytterhoeven
2012-08-16 18:18 ` Geert Uytterhoeven
2012-08-16 18:55 ` james northrup
2012-08-16 22:17 ` Andi Kleen
2012-08-16 22:17 ` Andi Kleen
2012-08-17 1:23 ` Mitch Harder
2012-08-17 1:23 ` Mitch Harder
2012-09-07 21:31 ` Andi Kleen
2012-09-07 21:31 ` Andi Kleen
2012-08-16 18:57 ` james northrup
2012-08-16 15:21 ` Jeff Garzik
2012-08-16 15:21 ` Jeff Garzik
2012-08-16 16:20 ` Andi Kleen
2012-08-16 16:20 ` Andi Kleen
2012-08-16 16:48 ` Jeff Garzik
2012-08-16 16:48 ` Jeff Garzik
2012-08-16 17:22 ` Johannes Stezenbach [this message]
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=20120816172251.GA25640@sig21.net \
--to=js@sig21.net \
--cc=andi@firstfloor.org \
--cc=chris.mason@fusionio.com \
--cc=jgarzik@pobox.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markus@oberhumer.com \
--cc=ngupta@vflare.org \
--cc=richard.weinberger@gmail.com \
--cc=rpurdie@openedhand.com \
/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: link
Be 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.