[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120816172251.GA25640@sig21.net>
Date: Thu, 16 Aug 2012 19:22:51 +0200
From: Johannes Stezenbach <js@...21.net>
To: Jeff Garzik <jgarzik@...ox.com>
Cc: Andi Kleen <andi@...stfloor.org>,
"Markus F.X.J. Oberhumer" <markus@...rhumer.com>,
linux-kernel@...r.kernel.org, chris.mason@...ionio.com,
linux-btrfs@...r.kernel.org, Nitin Gupta <ngupta@...are.org>,
Richard Purdie <rpurdie@...nedhand.com>,
richard -rw- weinberger <richard.weinberger@...il.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [GIT PULL] Update LZO compression
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists