Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757569Ab2HQBXK (ORCPT ); Thu, 16 Aug 2012 21:23:10 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:47766 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756901Ab2HQBXI (ORCPT ); Thu, 16 Aug 2012 21:23:08 -0400 MIME-Version: 1.0 In-Reply-To: <20120816221758.GM11413@one.firstfloor.org> References: <50299142.2030504@oberhumer.com> <20120814123937.GA14756@sig21.net> <502B8FE3.7080501@oberhumer.com> <20120815144539.GA8300@sig21.net> <502C92C3.7090701@oberhumer.com> <20120816150647.GA22010@sig21.net> <20120816232549.4d14a6aa@natsu> <20120816175234.GL11413@one.firstfloor.org> <20120816221758.GM11413@one.firstfloor.org> Date: Thu, 16 Aug 2012 20:23:06 -0500 Message-ID: Subject: Re: [GIT PULL] Update LZO compression From: Mitch Harder To: Andi Kleen Cc: james northrup , Geert Uytterhoeven , Roman Mamedov , Johannes Stezenbach , "Markus F.X.J. Oberhumer" , linux-kernel@vger.kernel.org, chris.mason@fusionio.com, linux-btrfs@vger.kernel.org, Nitin Gupta , Richard Purdie , richard -rw- weinberger , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1913 Lines: 43 On Thu, Aug 16, 2012 at 5:17 PM, Andi Kleen 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/