From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933570AbZHDXA5 (ORCPT ); Tue, 4 Aug 2009 19:00:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933517AbZHDXA5 (ORCPT ); Tue, 4 Aug 2009 19:00:57 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:41575 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933419AbZHDXA4 (ORCPT ); Tue, 4 Aug 2009 19:00:56 -0400 Date: Tue, 4 Aug 2009 16:00:43 -0700 From: Andrew Morton To: Albin Tonnerre Cc: sam@ravnborg.org, hpa@zytor.com, linux@arm.linux.org.uk, alain@knaff.lu, linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org, albin.tonnerre@free-electrons.com Subject: Re: [PATCH 3/6] Add support for LZO-compressed kernels Message-Id: <20090804160043.82b256d8.akpm@linux-foundation.org> In-Reply-To: <1249311501-23102-3-git-send-email-albin.tonnerre@free-electrons.com> References: <20090731093107.GA29704@merkur.ravnborg.org> <1249311501-23102-1-git-send-email-albin.tonnerre@free-electrons.com> <1249311501-23102-2-git-send-email-albin.tonnerre@free-electrons.com> <1249311501-23102-3-git-send-email-albin.tonnerre@free-electrons.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 Aug 2009 16:58:18 +0200 Albin Tonnerre wrote: > This is the first part of the lzo patch > The lzo compressor is worse than gzip at compression, but faster at > extraction. Here are some figures for an ARM board I'm working on: > > Uncompressed size: 3.24Mo > gzip 1.61Mo 0.72s > lzo 1.75Mo 0.48s > > So for a compression ratio that is still relatively close to gzip, it's > much faster to extract, at least in that case. Is 3.2Mb a typical kernel size for small systems? It sounds large. 0.24 seconds booting speedup sounds pretty thin. Adding a new decompression format will introduce more configuration/build/deployment complexities. How do we justify this? Did anyone look into just speeding up the gzip decompressor? > +#ifdef STATIC What is this STATIC thing for?