From: Sam Ravnborg <sam@ravnborg.org>
To: Satyam Sharma <satyam.sharma@gmail.com>
Cc: Jan Beulich <jbeulich@novell.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org, patches@x86-64.org
Subject: Re: [PATCH] x86: fix improper .init-type section references
Date: Wed, 13 Jun 2007 10:10:49 +0200 [thread overview]
Message-ID: <20070613081049.GA21364@uranus.ravnborg.org> (raw)
In-Reply-To: <a781481a0706130039r26e9522q98d9645809136ea7@mail.gmail.com>
On Wed, Jun 13, 2007 at 01:09:07PM +0530, Satyam Sharma wrote:
>
> i.e. don't discard anything at build time, and link the .exit.{text,
> data} sections
> into the kernel image for _all_ archs? (otherwise how do we avoid
> special-casing/
> checking for the arch in modpost and warn/not-warn about invalid/valid
> cases)
>
> But then why not simply lose the __exit (and .exit.*) altogether? Because
> __exit becomes redundant in the suggested changed semantics -- just mark
> all the cleanup code as __init too (when it's built-in, the only
> callsite for the
> cleanup code would be from the startup code in .init.*, and when modular,
> __init and __exit lose all relevance anyway).
The reason we do it today is to save memory in a memory constrained environment.
So with such a suggestion you should back it up with numbers.
How much RAM is wasted by keeping the __init and _exit sections
in memory for a normal embedded build?
You could try a random defconfig for arm or mips since they are
embedded in general. Using defconfig for i386 could tell us
a little but not that important.
And when evaluating the numbers think of maybe 8 MB RAM in total, no swap
storage, and sloow filesystem for permanent storage.
Sam
next prev parent reply other threads:[~2007-06-13 8:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-12 7:48 [PATCH] x86: fix improper .init-type section references Jan Beulich
2007-06-12 11:14 ` Satyam Sharma
2007-06-12 12:09 ` Satyam Sharma
2007-06-12 12:43 ` Jan Beulich
2007-06-12 13:32 ` Satyam Sharma
2007-06-12 13:49 ` Jan Beulich
2007-06-12 14:09 ` Satyam Sharma
2007-06-12 18:00 ` Sam Ravnborg
2007-06-13 3:18 ` Satyam Sharma
2007-06-13 4:35 ` Sam Ravnborg
2007-06-13 6:59 ` Jan Beulich
2007-06-13 7:39 ` Satyam Sharma
2007-06-13 7:49 ` Jan Beulich
2007-06-13 8:10 ` Sam Ravnborg [this message]
2007-06-12 17:56 ` Sam Ravnborg
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=20070613081049.GA21364@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=ak@suse.de \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@x86-64.org \
--cc=satyam.sharma@gmail.com \
--cc=venkatesh.pallipadi@intel.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 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.