Embedded Linux development
 help / color / mirror / Atom feed
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

      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