mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Adam J. Richter" <adam@yggdrasil.com>
To: kaos@ocs.com.au
Cc: linux-kernel@vger.kernel.org
Subject: Re: Rusty's module talk at the Kernel Summit
Date: Mon, 1 Jul 2002 09:12:56 -0700	[thread overview]
Message-ID: <200207011612.JAA01302@adam.yggdrasil.com> (raw)

Keith Owens wrote:
>Since modules are always allocated on page boundaries, discarding init
>sections is only a win if it reduces the final size of the module from
>m to m-n pages.  So far the pain of loading in multiple areas and
>adjusting the associated arch dependent tables after discard has
>outweighed any gain from discarding the init sections from modules.

	That would average out for modules larger than a page if the
distribution of the non-init sections modulo 4096 (or whatever
PAGE_CACHE_SIZE is on your architecture) is basically uniform.
You would be just as likely to free more bytes than the size of the .init
sections as a result of page granularity than to free fewer bytes.

	As an extereme illustration, imagine a module with 4095 bytes
of non-init data and 2 bytes of init data.  With the .init section loaded,
the module will occupy two pages.  Freeing the .init section will free
an entire page, making 4096 bytes available to the system, even though
only two bytes were in the .init section.

	On the linux-2.5.24 x86 machine on which I am composing this
email, 654 out of 983 modules (two thirds) have text+data+bss larger than
4096 bytes.  The byte count of these modules modulo 4096 is actually a bit
heavier on the low end, which bodes well for saving space by releasing .init
sections:

Module text+data+bss
size modulo 4096	 # of modules

0000...0511              102
0512...1023              108
1024...1535               81
1536...2047               76
2048...2559               71
2560...3071               90
3072...3583               69
3584...4095               57


	It would also be possible to achieve space savings for modules
with non-init text+data+bss sizes smaller than a page by allocating
their space with kmalloc(...,__GFP_HIGHMEM) instead of vmalloc.  This
would require loading the init and non-init parts as separate modules,
which would happen if this were implemented in what I regard as the
"easy" way, a way that would only delete lines from the current kernel
(but add code to insmod).

	Here is what I have in mind.  I believe that removal of .init
sections could be implemented entirely in user land (aside from
removing the include/inux/init.h code that disables init sections for
modules).  Insmod would allocate two kernel modules, one for the init
sections and the other for the regular sections.  Insmod would resolve
references between the two sections.  The temporary module for the
init sections would be loaded first, with no initialization routine.
The module with the real data would be loaded second, and would run
the initialization routine (even if the initialization routine were in
the temporary init module).  When the initialization routine
completed, regardless of sucess or failure, the temporary init module
would be unloaded.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

             reply	other threads:[~2002-07-01 16:10 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-01 16:12 Adam J. Richter [this message]
2002-07-01 17:02 ` jlnance
2002-07-03  5:01 ` Keith Owens
  -- strict thread matches above, loose matches on Subject: below --
2002-07-11  5:44 Adam J. Richter
2002-07-11  5:07 Adam J. Richter
2002-07-04 17:24 Adam J. Richter
2002-07-11  2:48 ` Rusty Russell
2002-07-11  2:45   ` David S. Miller
2002-07-11  3:30     ` Alexander Viro
2002-07-11  5:13       ` Rusty Russell
2002-07-11  6:37         ` Alexander Viro
2002-07-11  7:14           ` Rusty Russell
2002-07-11 10:54             ` Daniel Phillips
2002-07-11 17:37               ` Roman Zippel
2002-07-11 18:01                 ` Thunder from the hill
2002-07-11 18:50                   ` Daniel Phillips
2002-07-17 18:16                   ` bill davidsen
2002-07-17 19:35                     ` Thunder from the hill
2002-07-11 18:28                 ` Daniel Phillips
2002-07-11 19:48                   ` Roman Zippel
2002-07-11 20:29                     ` Daniel Phillips
2002-07-11 23:37                     ` Alexander Viro
2002-07-12  1:54                       ` Daniel Phillips
2002-07-12  3:53                       ` Rusty Russell
2002-07-12  6:49                         ` Kai Henningsen
2002-07-12 11:30                       ` Roman Zippel
2002-07-12  0:00               ` Rusty Russell
2002-07-12  6:57                 ` Kai Henningsen
2002-07-19  0:19           ` Richard Gooch
2002-07-22 16:29             ` Alexander Viro
2002-07-23  4:37               ` Richard Gooch
2002-07-11  4:02     ` Cort Dougan
2002-07-11  4:19       ` Arnaldo Carvalho de Melo
2002-07-11  4:46       ` Cort Dougan
2002-07-11  2:55   ` Arnaldo Carvalho de Melo
2002-07-11  3:01     ` Arnaldo Carvalho de Melo
2002-07-11  5:16     ` Rusty Russell
2002-07-03 15:53 Adam J. Richter
2002-07-03 17:07 ` Hugh Dickins
2002-07-03 18:46   ` Oliver Neukum
2002-07-03 23:25     ` Keith Owens
2002-07-03 23:09 ` Keith Owens
2002-07-03  7:31 Adam J. Richter
2002-07-03  8:54 ` Rogier Wolff
2002-07-03 12:27 ` Keith Owens
2002-07-03 14:10   ` Keith Owens
2002-07-01 17:20 Adam J. Richter
2002-07-01  8:45 Keith Owens

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=200207011612.JAA01302@adam.yggdrasil.com \
    --to=adam@yggdrasil.com \
    --cc=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®