public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Adrian Bunk <bunk@stusta.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>,
	Jonathan Campbell <jon@nerdgrounds.com>,
	linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: Patches for REALLY TINY 386 kernels
Date: Wed, 18 Jul 2007 20:44:40 +0200	[thread overview]
Message-ID: <20070718184440.GD3898@one.firstfloor.org> (raw)
In-Reply-To: <20070718183359.GK3801@stusta.de>

On Wed, Jul 18, 2007 at 08:33:59PM +0200, Adrian Bunk wrote:
> On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
> > Andi Kleen wrote:
> > > 
> > >> Already with these patches I can compile a zImage kernel that is 450kb
> > >> large (890kb decompressed)
> > > 
> > > The important part is not how big the vmlinux is, but how much
> > > memory is actually used after boot. 
> > > 
> > > I expect concentrating some of the dynamic data structures would
> > > be more fruitful in fact.
> > > 
> > 
> > Well, how big the vmlinux file is matters if it doesn't fit in memory
> > with enough time to get to the phase where it is dumping the init
> > sections.  *If that is not the issue*, then axing stuff like CPUID is a
> > major lose in terms of code maintainability for zero gain.
> 
> If this is an issue, then changing i386 back to discarding __exit code 

I don't think there is very much __exit code around in general.
e.g. a fairly fat x86-64 kernel here has a little over 5K.

> and data at linktime instead of runtime might make a bigger difference.

The problem is we would need separate exception tables for this then
or teach binutils about not warning. Hardly worth it for 5K.

In general it's more useful to focus on the real memory pigs 
(and measure first who they are) if you want to save memory. 
See also http://www.halobates.de/memorywaste.pdf

-Andi

  parent reply	other threads:[~2007-07-18 18:44 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-15 21:00 Patches for REALLY TINY 386 kernels Jonathan Campbell
2007-07-15 21:42 ` Nigel Cunningham
2007-07-15 22:45   ` Alan Cox
2007-07-15 23:12     ` Nigel Cunningham
2007-07-15 23:14       ` Satyam Sharma
2007-07-15 23:13         ` Arnd Bergmann
2007-07-15 23:28           ` Satyam Sharma
2007-07-15 23:05 ` Adrian Bunk
2007-07-15 23:08 ` H. Peter Anvin
2007-07-17 10:59 ` Jan Engelhardt
2007-07-17 19:30   ` Matt Mackall
2007-07-18  2:33 ` Andi Kleen
2007-07-18 15:55   ` H. Peter Anvin
2007-07-18 18:20     ` Andi Kleen
2007-07-18 18:29       ` Jan Engelhardt
2007-07-18 18:38         ` Andi Kleen
2007-07-18 18:45           ` Jan Engelhardt
2007-07-18 18:47             ` Andi Kleen
2007-07-18 20:24         ` John Stoffel
2007-07-18 18:33     ` Adrian Bunk
2007-07-18 18:42       ` Jan Engelhardt
2007-07-18 18:44       ` Andi Kleen [this message]
2007-07-18 19:00       ` H. Peter Anvin
2007-07-21 10:09         ` Oleg Verych
2007-07-18 19:41     ` Matt Mackall
2007-07-18 19:50       ` H. Peter Anvin
2007-07-18 20:10       ` Andi Kleen
2007-07-18 20:24         ` H. Peter Anvin
2007-07-18 21:04           ` Andi Kleen
2007-07-18 22:17             ` H. Peter Anvin
2007-07-30 17:59             ` Denis Vlasenko
2007-07-18 20:41         ` Matt Mackall
2007-07-20  7:27           ` Uwe Hermann
2007-07-20  7:35             ` Andi Kleen
2007-07-24 14:49               ` Helge Hafting
2007-07-24 20:50                 ` Yinghai Lu
2007-07-24 22:56                   ` Adrian Bunk
2007-07-25  0:55                     ` Yinghai Lu
2007-07-24 22:45     ` Willy Tarreau
     [not found] <8HjYY-4Jk-15@gated-at.bofh.it>
     [not found] ` <8HlxM-7iT-13@gated-at.bofh.it>
     [not found]   ` <8HlxL-7iT-11@gated-at.bofh.it>
     [not found]     ` <8HlHq-7vR-17@gated-at.bofh.it>
     [not found]       ` <8HlHr-7vR-25@gated-at.bofh.it>
2007-07-16 13:12         ` Bodo Eggert

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=20070718184440.GD3898@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=bunk@stusta.de \
    --cc=hpa@zytor.com \
    --cc=jon@nerdgrounds.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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