Thread (15 messages) 15 messages, 8 authors, 2012-08-17

[GIT PULL] Update LZO compression

From: Mitch Harder <hidden>
Date: 2012-08-17 01:23:10
Also in: linux-btrfs, lkml

Possibly related (same subject, not in this thread)

On Thu, Aug 16, 2012 at 5:17 PM, Andi Kleen [off-list ref] wrote:
On Thu, Aug 16, 2012 at 11:55:06AM -0700, james northrup wrote:
quoted
looks like ARM results are inconclusive from a lot of folks without
bandwidth to do a write-up, what about just plain STAGING status for ARM so
the android tweakers can beat on it for a while?
Staging only really works for new drivers, not for updating existing
library functions like this.

I suppose you could keep both and have the architecture select with a
CONFIG.
I've been doing some rough benchmarking with the updated LZO in btrfs.

My tests primarily consist of timing some typical copying, git
manipulating, and running rsync using a set of kernel git sources.
Git sources are typically about 50% pack files which won't compress
very well, with the remainder being mostly highly compressible source
files.

Of course, any underlying speed improvement attributable only to LZO
is not shown by test like this. But I thought it would be interesting
to see the impact in some typical real-world btrfs operations.

I was seeing between 3-9% improvement in speed with the new LZO.

Copying several directories of git sources showed the most
improvement, ~9%.  Typical git operations, such as a git checkout or
git status where only showing 3-5% improvement, which is close to the
noise level of my tests.  Running multiple rsync processes showed a 5%
improvement.

With only 10 trials (5 with each LZO), I can't say I would
statistically hang my hat on these numbers.

Given all the other stuff that is going on in my rough benchmarks, a
3-9% improvement from a single change is probably pretty good.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help