From: Lasse Collin <lasse.collin@tukaani.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: Linux Kernel Development <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
Linux Embedded Maillist <linux-embedded@vger.kernel.org>
Subject: Re: [PATCH 1/2] Squashfs: add XZ compression support
Date: Sat, 11 Dec 2010 00:49:18 +0200 [thread overview]
Message-ID: <201012110049.18135.lasse.collin@tukaani.org> (raw)
In-Reply-To: <4D00726D.3080503@lougher.demon.co.uk>
On 2010-12-09 Phillip Lougher wrote:
> + stream->state = xz_dec_init(XZ_PREALLOC, block_size);
This sets the preallocated LZMA2 dictionary size to Squashfs block size,
which allows the best compression ratio for the given block size (bigger
values would be waste of memory). XZ decompressor needs about 30 KiB of
memory plus the dictionary. So with 1 MiB Squashfs block size a little
over 1 MiB of memory is needed by the XZ decompressor.
Would it be useful to support smaller dictionaries without reducing the
Squashfs block size? It would save RAM while increasing the Squashfs
image size less than if also the block size was reduced. Reasonable
dictionary sizes could be e.g. 75 %, 50 %, or 25 % of the Squashfs block
size. The size increase of the Squashfs image will vary a lot depending
on the files in it, but e.g. dict_size = block_size / 2 won't
necessarily increase the image size more than 1 %.
I don't know if this kind of RAM savings matter on embedded systems. I
hope someone else can comment. My point in this email is only to let
others know that reducing the RAM usage is possible without reducing the
Squashfs block size.
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
prev parent reply other threads:[~2010-12-10 22:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-09 6:08 [PATCH 1/2] Squashfs: add XZ compression support Phillip Lougher
2010-12-10 22:49 ` Lasse Collin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201012110049.18135.lasse.collin@tukaani.org \
--to=lasse.collin@tukaani.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phillip@lougher.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox