* fastboot: unpacking initramfs faster @ 2009-03-24 7:39 Andreas Robinson 0 siblings, 0 replies; 7+ messages in thread From: Andreas Robinson @ 2009-03-24 7:39 UTC (permalink / raw) To: Arjan van de Ven; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <cj9yI-540-17@gated-at.bofh.it>]
* Re: fastboot: unpacking initramfs faster [not found] <cj9yI-540-17@gated-at.bofh.it> @ 2009-03-24 22:11 ` Bodo Eggert 2009-03-26 7:52 ` Andreas Robinson 0 siblings, 1 reply; 7+ messages in thread From: Bodo Eggert @ 2009-03-24 22:11 UTC (permalink / raw) To: Andreas Robinson, Arjan van de Ven, linux-kernel Andreas Robinson <andr345@gmail.com> wrote: > 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 could not stall my system by gzip</dev/urandom>/dev/null. Maybe you accidentally used vfork? > 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.) Why not make a new set? http://7eggert.dyndns.org:8080/l/bgz.tar.gz ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fastboot: unpacking initramfs faster 2009-03-24 22:11 ` Bodo Eggert @ 2009-03-26 7:52 ` Andreas Robinson 2009-03-26 11:26 ` Bodo Eggert 0 siblings, 1 reply; 7+ messages in thread From: Andreas Robinson @ 2009-03-26 7:52 UTC (permalink / raw) To: 7eggert; +Cc: Arjan van de Ven, linux-kernel On Tue, 2009-03-24 at 23:11 +0100, Bodo Eggert wrote: > Andreas Robinson <andr345@gmail.com> wrote: > > > 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 could not stall my system by gzip</dev/urandom>/dev/null. > Maybe you accidentally used vfork? No, this was an in-kernel test. I used the Arjan's new async facility which calls kthread_create(). > > 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.) > > Why not make a new set? http://7eggert.dyndns.org:8080/l/bgz.tar.gz Hmm, well if you think there is a chance of it being accepted, then sure! I'll cook something up, but will be looking to use LZO first since it's a bit faster to begin with. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fastboot: unpacking initramfs faster 2009-03-26 7:52 ` Andreas Robinson @ 2009-03-26 11:26 ` Bodo Eggert 2009-03-26 11:57 ` Andreas Robinson 0 siblings, 1 reply; 7+ messages in thread From: Bodo Eggert @ 2009-03-26 11:26 UTC (permalink / raw) To: Andreas Robinson; +Cc: 7eggert, Arjan van de Ven, linux-kernel On Thu, 26 Mar 2009, Andreas Robinson wrote: > On Tue, 2009-03-24 at 23:11 +0100, Bodo Eggert wrote: > > Andreas Robinson <andr345@gmail.com> wrote: > > > 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.) > > > > Why not make a new set? http://7eggert.dyndns.org:8080/l/bgz.tar.gz > > Hmm, well if you think there is a chance of it being accepted, then > sure! I'll cook something up, but will be looking to use LZO first since > it's a bit faster to begin with. It's small enough, and now I've updated it to support lzo and put a license into the files. Thinking about it: It's now very kernel-specific, other users might like a block signature to make it robust against errors - e.g. in the middle of a .tar.bgz file. I think I'll change that soon and put 0x55aa in front of each block. -- Borges sumus. Resistere inutile est. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fastboot: unpacking initramfs faster 2009-03-26 11:26 ` Bodo Eggert @ 2009-03-26 11:57 ` Andreas Robinson 2009-03-26 12:56 ` Bodo Eggert 0 siblings, 1 reply; 7+ messages in thread From: Andreas Robinson @ 2009-03-26 11:57 UTC (permalink / raw) To: Bodo Eggert; +Cc: Arjan van de Ven, linux-kernel On Thu, 2009-03-26 at 12:26 +0100, Bodo Eggert wrote: > On Thu, 26 Mar 2009, Andreas Robinson wrote: > > On Tue, 2009-03-24 at 23:11 +0100, Bodo Eggert wrote: [snip] > > > Why not make a new set? http://7eggert.dyndns.org:8080/l/bgz.tar.gz > > > > Hmm, well if you think there is a chance of it being accepted, then > > sure! I'll cook something up, but will be looking to use LZO first since > > it's a bit faster to begin with. > > It's small enough, and now I've updated it to support lzo and put a > license into the files. The file permissions are wrong, I'm not allowed to download it. > Thinking about it: It's now very kernel-specific, other users might like a > block signature to make it robust against errors - e.g. in the middle of a > .tar.bgz file. I think I'll change that soon and put 0x55aa in front of > each block. I think we'll want an optional checksum of the compressed data. Suppose bit 32 in the compressed block size field is set, the next field is the block's Adler32 checksum. (the adler32 source is in include/linux/zutil.h) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fastboot: unpacking initramfs faster 2009-03-26 11:57 ` Andreas Robinson @ 2009-03-26 12:56 ` Bodo Eggert 2009-03-26 16:05 ` Andreas Robinson 0 siblings, 1 reply; 7+ messages in thread From: Bodo Eggert @ 2009-03-26 12:56 UTC (permalink / raw) To: Andreas Robinson; +Cc: Bodo Eggert, Arjan van de Ven, linux-kernel On Thu, 26 Mar 2009, Andreas Robinson wrote: > On Thu, 2009-03-26 at 12:26 +0100, Bodo Eggert wrote: > > On Thu, 26 Mar 2009, Andreas Robinson wrote: > > > On Tue, 2009-03-24 at 23:11 +0100, Bodo Eggert wrote: > [snip] > > > > Why not make a new set? http://7eggert.dyndns.org:8080/l/bgz.tar.gz > The file permissions are wrong, I'm not allowed to download it. fixed > > Thinking about it: It's now very kernel-specific, other users might like a > > block signature to make it robust against errors - e.g. in the middle of a > > .tar.bgz file. I think I'll change that soon and put 0x55aa in front of > > each block. > > I think we'll want an optional checksum of the compressed data. > Suppose bit 32 in the compressed block size field is set, the next field > is the block's Adler32 checksum. > (the adler32 source is in include/linux/zutil.h) I will think about it. -- Funny quotes: 5. 99 percent of lawyers give the rest a bad name. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: fastboot: unpacking initramfs faster 2009-03-26 12:56 ` Bodo Eggert @ 2009-03-26 16:05 ` Andreas Robinson 0 siblings, 0 replies; 7+ messages in thread From: Andreas Robinson @ 2009-03-26 16:05 UTC (permalink / raw) To: Bodo Eggert; +Cc: Arjan van de Ven, linux-kernel Here is a quick and dirty patch that works for me. Applies to current git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-x86.git Work on monolithic-kernel decompression and multithreading is next. >From 27d64e5fca08d695282da219eb71e5fca978a9d2 Mon Sep 17 00:00:00 2001 From: Andreas Robinson <andr345@gmail.com> Date: Thu, 26 Mar 2009 16:44:14 +0100 Subject: [PATCH] lib: support lzo-compressed initramfs images Impact: Allows faster unpacking of the initial ramdisk. LZO files are marginally larger than gzip, about 7% for the best compression method lzo1x_999, but decompress about 30% faster on x86 hardware. This patch supports a new stream format generated by a userspace tool named blzo. Patch content: * necessary additions to Kconfig and makefiles * a simple initramfs decompressor --- include/linux/decompress/ublzo.h | 12 ++++++ lib/Kconfig | 4 ++ lib/Makefile | 1 + lib/decompress.c | 5 +++ lib/decompress_ublzo.c | 75 ++++++++++++++++++++++++++++++++++++++ usr/Kconfig | 9 +++++ 6 files changed, 106 insertions(+), 0 deletions(-) create mode 100644 include/linux/decompress/ublzo.h create mode 100644 lib/decompress_ublzo.c diff --git a/include/linux/decompress/ublzo.h b/include/linux/decompress/ublzo.h new file mode 100644 index 0000000..e453d07 --- /dev/null +++ b/include/linux/decompress/ublzo.h @@ -0,0 +1,12 @@ +#ifndef DECOMPRESS_UBLZO_H +#define DECOMPRESS_UBLZO_H + +int ublzo(unsigned char *, int, + int(*fill)(void*, unsigned int), + int(*flush)(void*, unsigned int), + unsigned char *output, + int *posp, + void(*error)(char *x) + ); + +#endif diff --git a/lib/Kconfig b/lib/Kconfig index e3b7d7a..9e5c7f1 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -104,6 +104,10 @@ config LZO_DECOMPRESS # These all provide a common interface (hence the apparent duplication with # ZLIB_INFLATE; DECOMPRESS_GZIP is just a wrapper.) # +config DECOMPRESS_BLZO + select LZO_DECOMPRESS + tristate + config DECOMPRESS_GZIP select ZLIB_INFLATE tristate diff --git a/lib/Makefile b/lib/Makefile index b24222c..9ee48e8 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/ obj-$(CONFIG_LZO_COMPRESS) += lzo/ obj-$(CONFIG_LZO_DECOMPRESS) += lzo/ +lib-$(CONFIG_DECOMPRESS_BLZO) += decompress_ublzo.o lib-$(CONFIG_DECOMPRESS_GZIP) += decompress_inflate.o lib-$(CONFIG_DECOMPRESS_BZIP2) += decompress_bunzip2.o lib-$(CONFIG_DECOMPRESS_LZMA) += decompress_unlzma.o diff --git a/lib/decompress.c b/lib/decompress.c index d2842f5..8c189a0 100644 --- a/lib/decompress.c +++ b/lib/decompress.c @@ -9,10 +9,14 @@ #include <linux/decompress/bunzip2.h> #include <linux/decompress/unlzma.h> #include <linux/decompress/inflate.h> +#include <linux/decompress/ublzo.h> #include <linux/types.h> #include <linux/string.h> +#ifndef CONFIG_DECOMPRESS_BLZO +# define ublzo NULL +#endif #ifndef CONFIG_DECOMPRESS_GZIP # define gunzip NULL #endif @@ -28,6 +32,7 @@ static const struct compress_format { const char *name; decompress_fn decompressor; } compressed_formats[] = { + { {'B', 'L'}, "blzo", ublzo }, { {037, 0213}, "gzip", gunzip }, { {037, 0236}, "gzip", gunzip }, { {0x42, 0x5a}, "bzip2", bunzip2 }, diff --git a/lib/decompress_ublzo.c b/lib/decompress_ublzo.c new file mode 100644 index 0000000..136f57f --- /dev/null +++ b/lib/decompress_ublzo.c @@ -0,0 +1,75 @@ +/* Simple LZO file format decompressor. + * + * Copyright (C) 2009 Andreas Robinson <andr345@gmail.com> + * + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 2 of the License, or + * (at your option) any later version. + */ + +#include <linux/types.h> +#include <linux/lzo.h> + +#ifndef STATIC +#include <linux/decompress/ublzo.h> +#endif /* STATIC */ +#include <linux/decompress/mm.h> + +#define BLZO_BLOCK_SIZE 65536 + +int INIT ublzo(unsigned char *inbuf, int len, + int(*fill)(void*, unsigned int), + int(*flush)(void*, unsigned int), + unsigned char *output, + int *posp, + void(*error)(char *x)) +{ + int ret = LZO_E_OK; + size_t start_len, in_len, out_len; + void *out; + + start_len = len; + + if (fill) { + error("the decompress 'fill' feature is not yet implemented"); + return LZO_E_ERROR; + } else { + out = malloc(BLZO_BLOCK_SIZE); + if (!out) + panic("Cannot allocate decompression buffers!"); + + if (memcmp("BLZO", inbuf, 4) != 0) + return LZO_E_ERROR; + + inbuf += 4; + len -= 4; + + while (len > 0) { + in_len = (inbuf[0] << 8) + inbuf[1]; + inbuf += 2; + len -= 2; + if (in_len == 0) + goto done; + + out_len = BLZO_BLOCK_SIZE; + ret = lzo1x_decompress_safe(inbuf, in_len, out, &out_len); + if (ret != LZO_E_OK) { + error("error in LZO archive"); + goto done; + } + + inbuf += in_len; + len -= in_len; + flush(out, out_len); + } + } + +done: + free(out); + *posp = start_len - len; + return ret; +} + +#define decompress ublzo diff --git a/usr/Kconfig b/usr/Kconfig index 43a3a0f..ff2b15c 100644 --- a/usr/Kconfig +++ b/usr/Kconfig @@ -45,6 +45,15 @@ config INITRAMFS_ROOT_GID If you are not sure, leave it set to "0". +config RD_BLZO + bool "Initial ramdisk compressed using blzo" + default y + depends on BLK_DEV_INITRD=y + select DECOMPRESS_BLZO + help + Support loading of a blzo encoded initial ramdisk or cpio buffer. + If unsure, say Y. + config RD_GZIP bool "Initial ramdisk compressed using gzip" default y -- 1.5.6.3 ^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-03-26 16:05 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-24 7:39 fastboot: unpacking initramfs faster Andreas Robinson
[not found] <cj9yI-540-17@gated-at.bofh.it>
2009-03-24 22:11 ` Bodo Eggert
2009-03-26 7:52 ` Andreas Robinson
2009-03-26 11:26 ` Bodo Eggert
2009-03-26 11:57 ` Andreas Robinson
2009-03-26 12:56 ` Bodo Eggert
2009-03-26 16:05 ` Andreas Robinson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox