DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:cc:content-type:date:message-id:mime-version
         :x-mailer:content-transfer-encoding;
        b=yAk/zrT36UXmnoT98/JpuJ/2OiFH32np1/BNWjnCkZ2zUiUKuaE1intDWNyXQpaD7P
         aGBnBI3TPpcskF0Fq2Ymgb5KGtAAz+jFUKif8gKUXhj3JQhPo+b1GaKlvLD7y6w8A36j
         EC1ZPPITD7sWmH0RPmVuF5TTb23ffZt7Nw/dw=
Subject: fastboot: unpacking initramfs faster
From: Andreas Robinson <andr345@gmail.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: linux-kernel@vger.kernel.org
Content-Type: text/plain
Date: Tue, 24 Mar 2009 08:39:08 +0100
Message-Id: <1237880348.7725.17.camel@andreas-desktop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1579
Lines: 45

Hi,

here's a quick update on what can be done to make initramfs unpacking
faster that I suggested a few weeks ago. There results are mixed.


The bad:

I tried running the initramfs unpacking asynchronously (and earlier) but
ran into a curious problem: The parent thread stalled until
decompression was done. I don't know why - I made sure that the two
threads ran on different cores. Perhaps the parent was cache starved.

I then looked at multithreaded decompression and found that neither gzip
files nor deflate streams provide enough information (eg block lengths)
to let you share the decompression among threads.

It can be done of course, but obviously not without modifying file
formats and userspace tools. 

(Thoughts of snowballs and hell presented themselves at this point.)


The good:

LZO compression is roughly twice as fast as gunzip while files are only
about 7% bigger. The file format is multiprocessing friendly and the
decompressor is already in the mainline kernel.

I estimate that single-threaded LZO would cut the unpacking time almost
in half even on a low-end PC with a slow drive, like the Eee 901.

Finally, someone already wrote support for bzip2 and lzma compressed
initramfs. It's in the -tip tree. Adding LZO to that list should be
straightforward so that's where I'm going next.

Cheers,
Andreas


--
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/