Re: [GIT PULL] Update LZO compression

[Jeff Garzik]

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




--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Update LZO compression

[Jeff Garzik]

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.


Jeff




--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Notes on support for multiple devices for a single filesystem

[Jeff Garzik]

Kay Sievers wrote:

Features like the very nice and useful directory-based snapshots would
also not be possible with simple block-based multi-devices, right?


Snapshotting via block device has always been an incredibly dumb hack, 
existing primarily because filesystem-based snapshots did not exist for 
the filesystem in question.


Snapshots are better at the filesystem level because the filesystem is 
the only entity that knows when the filesystem is quiescent and 
snapshot-able.


ISTR we had to add -write_super_lockfs() to hack in support for LVM in 
this manner, rather than doing it the right way.


Jeff


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html