All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Bertrand Jacquin <beber@meleeweb.net>, linux-kbuild@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Willy Tarreau <w@1wt.eu>
Subject: Re: [PATCH 2/3] kbuild: handle module compression while running 'make modules_install'.
Date: Thu, 21 Aug 2014 01:39:59 +0930	[thread overview]
Message-ID: <87r40bi1m0.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1408474660-24999-3-git-send-email-beber@meleeweb.net>

Bertrand Jacquin <beber@meleeweb.net> writes:

> Since module-init-tools (gzip) and kmod (gzip and xz) support compressed
> modules, it could be useful to include a support for compressing modules
> right after having them installed. Doing this in kbuild instead of per
> distro can permit to make this kind of usage more generic.
>
> This patch add a Kconfig entry to "Enable loadable module support" menu
> and let you choose to compress using gzip (default) or xz.
>
> Both gzip and xz does not used any extra -[1-9] option since Andi Kleen
> and Rusty Russell prove no gain is made using them. gzip is called with -n
> argument to avoid storing original filename inside compressed file, that
> way we can save some more bytes.
>
> On a v3.16 kernel, 'make allmodconfig' generated 4680 modules for a
> total of 378MB (no strip, no sign, no compress), the following table
> shows observed disk space gain based on the allmodconfig .config :
>
>        |           time                |
>        +-------------+-----------------+
>        | manual .ko  |       make      | size | percent
>        | compression | modules_install |      | gain
>        +-------------+-----------------+------+--------
>   -    |             |     18.61s      | 378M |
>   GZIP |   3m16s     |     3m37s       | 102M | 73.41%
>   XZ   |   5m22s     |     5m39s       |  77M | 79.83%
>
> The gain for restricted environnement seems to be interesting while
> uncompress can be time consuming but happens only while loading a module,
> that is generally done only once.
>
> This is fully compatible with signed modules while the signed module is
> compressed. module-init-tools or kmod handles decompression
> and provide to other layer the uncompressed but signed payload.
>
> Reviewed-by: Willy Tarreau <w@1wt.eu>
> Signed-off-by: Bertrand Jacquin <beber@meleeweb.net>

Thanks, applied these two as well.  They'll go in *next* merge window
(ie. 3.18).

Cheers.
Rusty.

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Bertrand Jacquin <beber@meleeweb.net>, linux-kbuild@vger.kernel.org
Cc: Bertrand Jacquin <beber@meleeweb.net>,
	linux-kernel@vger.kernel.org, Willy Tarreau <w@1wt.eu>
Subject: Re: [PATCH 2/3] kbuild: handle module compression while running 'make modules_install'.
Date: Thu, 21 Aug 2014 01:39:59 +0930	[thread overview]
Message-ID: <87r40bi1m0.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1408474660-24999-3-git-send-email-beber@meleeweb.net>

Bertrand Jacquin <beber@meleeweb.net> writes:

> Since module-init-tools (gzip) and kmod (gzip and xz) support compressed
> modules, it could be useful to include a support for compressing modules
> right after having them installed. Doing this in kbuild instead of per
> distro can permit to make this kind of usage more generic.
>
> This patch add a Kconfig entry to "Enable loadable module support" menu
> and let you choose to compress using gzip (default) or xz.
>
> Both gzip and xz does not used any extra -[1-9] option since Andi Kleen
> and Rusty Russell prove no gain is made using them. gzip is called with -n
> argument to avoid storing original filename inside compressed file, that
> way we can save some more bytes.
>
> On a v3.16 kernel, 'make allmodconfig' generated 4680 modules for a
> total of 378MB (no strip, no sign, no compress), the following table
> shows observed disk space gain based on the allmodconfig .config :
>
>        |           time                |
>        +-------------+-----------------+
>        | manual .ko  |       make      | size | percent
>        | compression | modules_install |      | gain
>        +-------------+-----------------+------+--------
>   -    |             |     18.61s      | 378M |
>   GZIP |   3m16s     |     3m37s       | 102M | 73.41%
>   XZ   |   5m22s     |     5m39s       |  77M | 79.83%
>
> The gain for restricted environnement seems to be interesting while
> uncompress can be time consuming but happens only while loading a module,
> that is generally done only once.
>
> This is fully compatible with signed modules while the signed module is
> compressed. module-init-tools or kmod handles decompression
> and provide to other layer the uncompressed but signed payload.
>
> Reviewed-by: Willy Tarreau <w@1wt.eu>
> Signed-off-by: Bertrand Jacquin <beber@meleeweb.net>

Thanks, applied these two as well.  They'll go in *next* merge window
(ie. 3.18).

Cheers.
Rusty.

  reply	other threads:[~2014-08-20 19:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19 18:57 [PATCHv2 0/3] handle module compression at install Bertrand Jacquin
2014-08-19 18:57 ` [PATCH 1/3] modinst: wrap long lines in order to enhance cmd_modules_install Bertrand Jacquin
2014-08-19 22:02   ` Jim Davis
2014-08-20 16:08     ` Rusty Russell
2014-08-19 18:57 ` [PATCH 2/3] kbuild: handle module compression while running 'make modules_install' Bertrand Jacquin
2014-08-20 16:09   ` Rusty Russell [this message]
2014-08-20 16:09     ` Rusty Russell
2014-10-12 15:50   ` Andev
2014-10-12 16:40     ` Willy Tarreau
2014-10-12 17:06       ` Andev
2014-08-19 18:57 ` [PATCH 3/3] modsign: lookup lines ending in .ko in .mod files Bertrand Jacquin
2014-08-20 16:06   ` Rusty Russell
2014-08-20 16:06     ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2014-08-16 18:50 [PATCH 0/3] handle module compression at install Bertrand Jacquin
2014-08-16 18:50 ` [PATCH 2/3] kbuild: handle module compression while running 'make modules_install' Bertrand Jacquin
2014-08-19 13:17   ` Andi Kleen
2014-08-19 15:22     ` Bertrand Jacquin
2014-08-19 23:49       ` Andi Kleen
2014-08-20 15:04         ` Rusty Russell
2014-08-20 15:04           ` Rusty Russell
2014-08-19 17:55     ` Rusty Russell
2014-08-19 18:54       ` Bertrand Jacquin

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=87r40bi1m0.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=beber@meleeweb.net \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=w@1wt.eu \
    /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.