linux-kernel - Re: [GIT PULL] Update LZO compression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 16 Aug 2012 20:23:06 -0500
From:	Mitch Harder <mitch.harder@...ayonlinux.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	james northrup <northrup.james@...il.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Roman Mamedov <rm@...anrm.ru>,
	Johannes Stezenbach <js@...21.net>,
	"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 5:17 PM, Andi Kleen <andi@...stfloor.org> wrote:
> On Thu, Aug 16, 2012 at 11:55:06AM -0700, james northrup wrote:
>> 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.
--
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/