All of lore.kernel.org
 help / color / mirror / Atom feed
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: kaos@ocs.com.au, linux-kernel@vger.kernel.org
Subject: Re: Rusty's module talk at the Kernel Summit
Date: Wed, 3 Jul 2002 10:54:34 +0200 (MEST)	[thread overview]
Message-ID: <200207030854.KAA02662@cave.bitwizard.nl> (raw)
In-Reply-To: <200207030731.AAA03720@adam.yggdrasil.com> from "Adam J. Richter" at "Jul 3, 2002 00:31:35 am"

Adam J. Richter wrote:
> >The total saving over all 2.5.24 modules is 4% of the total module
> >sizes, rounded to page boundaries.
> 
>       As individual space optimizations go, 4% is respectable,
> especially for something that has no cost, helps detect bugs and
> simplifies the kernel.  It is hard to think of many potential
> other space improvements that would as effective, especially as
> function of implementation effort.  In comparison, my vmlinux is
> 5% init sections.  So, if init sections are worth it for the
> core kernel, they should be worth it for modules.

Ehmmm. You normally load one big 1Mb kernel, freeing about 40 or 50k
at init time.

You normally load a couple of modules, totalling much less. 

Hmm. Just checked on a system with sound as modules, I see half a
megabyte of modules. So maybe that 20k is worth it. On the other hand,
you only load half a megabyte of shit if you have the RAM to spare.
20k is not worth the time I spend typing this....


> >Most of that saving comes from a few modules.
> 
> 	This makes me wonder if __init procedures are not being
> aggressively identified.  I wonder if people would use __init a little
> more if they knew they would get the benefit of it in the module case.
> Perhaps someday someone will write a tool to identify procedures that
> are only called from init sections.

Sometimes the "error path" will try to reset/reinit the chip. You will
not see that happening during a normal usage cycle, but you will get
bitten if you remove the init based on an actual call-trace.... 

> 	Kernel modules have been a way of life for me for years, and I
> don't think I've ever caught a kernel bug by the mechanism that you

This happens often enough "during development" that the bugs get fixed
before you get to see them....

> describe.  However, I see no harm in having a debugging option that
> always vmalloc'ed kernel modules.  This faciilty could be entirely
> configuarable from user level by having insmod allocate a module of
> *exactly* one page for modules that were less than a page (since you
> would only want to kmalloc modules that were *less* than one page).

As far as I know, kmallocing more than half a page will actually
allocate the whole page. 

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

  reply	other threads:[~2002-07-03  8:53 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-03  7:31 Rusty's module talk at the Kernel Summit Adam J. Richter
2002-07-03  8:54 ` Rogier Wolff [this message]
2002-07-03 12:27 ` Keith Owens
2002-07-03 14:10   ` 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-01 17:20 Adam J. Richter
2002-07-01 16:12 Adam J. Richter
2002-07-01 17:02 ` jlnance
2002-07-03  5:01 ` Keith Owens
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=200207030854.KAA02662@cave.bitwizard.nl \
    --to=r.e.wolff@bitwizard.nl \
    --cc=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 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.