From: Andrew Morton <akpm@linux-foundation.org>
To: Jim Keniston <jkenisto@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: [PATCH] zlib: Slim down zlib_deflate workspace when possible
Date: Tue, 1 Mar 2011 16:30:26 -0800 [thread overview]
Message-ID: <20110301163026.f1b5fa56.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110228210420.15417.41430.stgit@localhost.localdomain>
On Mon, 28 Feb 2011 13:04:20 -0800
Jim Keniston <jkenisto@us.ibm.com> wrote:
> Instead of always creating a huge (268K) deflate_workspace with the
> maximum compression parameters (windowBits=15, memLevel=8), allow the
> caller to obtain a smaller workspace by specifying smaller parameter
> values -- via zlib_deflate_workspacesize2().
>
> For example, when capturing oops and panic reports to a medium with
> limited capacity, such as NVRAM, compression may be the only way to
> capture the whole report. In this case, a small workspace (24K works
> fine) is a win, whether you allocate the workspace when you need it
> (i.e., during an oops or panic) or at boot time.
>
> I've verified that this patch works with all accepted values of
> windowBits (positive and negative), memLevel, and compression level;
> and also via the existing zlib_deflate_workspacesize() /
> zlib_deflateInit() interface.
zlib_deflate_workspacesize() has seven callsites. Rather than creating
the new zlib_deflate_workspacesize2() I suggest that you just add the
two new args to zlib_deflate_workspacesize() and then adjust the
existing callers.
>
> diff --git a/include/linux/zlib.h b/include/linux/zlib.h
> index 40c49cb..3f15036 100644
> --- a/include/linux/zlib.h
> +++ b/include/linux/zlib.h
> @@ -179,11 +179,21 @@ typedef z_stream *z_streamp;
>
> /* basic functions */
>
> +extern int zlib_deflate_workspacesize2 (int windowBits, int memLevel);
> +/*
> + Returns the number of bytes that needs to be allocated for a per-
> + stream workspace with the specified parameters. A pointer to this
> + number of bytes should be returned in stream->workspace before
> + calling zlib_deflateInit2(); and the windowBits and memLevel
> + parameters passed to zlib_deflateInit2() must not exceed those
> + passed here.
> +*/
Wait. The (unspeakably poxy) zlib code puts comments *after* the thing
which they're commenting on? Who did that and is he bigger than me?
next prev parent reply other threads:[~2011-03-02 0:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 21:04 [PATCH] zlib: Slim down zlib_deflate workspace when possible Jim Keniston
2011-03-02 0:30 ` Andrew Morton [this message]
2011-03-03 1:05 ` Jim Keniston
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=20110301163026.f1b5fa56.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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