All of lore.kernel.org
 help / color / mirror / Atom feed
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?


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.