From: Michael Ellerman <michael@ellerman.id.au>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org, Anton Blanchard <anton@samba.org>
Subject: Re: 64bit kernel is huge
Date: Mon, 28 Sep 2009 19:13:28 +1000 [thread overview]
Message-ID: <1254129208.5959.7.camel@concordia> (raw)
In-Reply-To: <1254125220.8421.21.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
On Mon, 2009-09-28 at 18:07 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-09-28 at 17:45 +1000, Anton Blanchard wrote:
> > Hi,
> >
> > I've found at least one machine that wont boot 2.6.31-rc* with a
> > pseries_defconfig. If I move real-base from 0xc00000 to 0xd00000 it
> > boots fine.
> >
> > # size vmlinux
> > text data bss dec hex filename
> > 9812942 1982496 1105228 12900666 c4d93a vmlinux
> >
> > Looks like we blow right through the 12MB mark. It desperately needs to eat
> > less and lose weight.
> > 262144 kstat_irqs_all
> > 131072 irq_desc
> > 16384 irq_stat
> >
> > Could we dynamically allocate our irq structures?
>
> We still want one big array, unless we go to sparse IRQ numbering like
> x86 but we'd have to also adapt the remapping stuff. Definitely to put
> on a list somewhere for people who want to pick up something to do :-)
Actually I've already been looking at it. The easy step is to enable
SPARSE_IRQ, the harder step is to get rid of our irq_map. But that's not
that big.
I'll try and get them polished for the next merge window.
> It's hard to properly dynamically size it. I'd rather have a "capacity"
> of _lots_ and sparsely populate the array (a tree ?) because we never
> know with MSIs etc... how many we'll really need.
>
> At the -very-least- we could make NR_IRQS a CONFIG option.
Yeah I have a patch for that too, I'll post it. It's no good for distros
but for custom kernels it could be quite handy, small partitions with
virtual most things don't really need many interrupts.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-09-28 9:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-28 7:45 64bit kernel is huge Anton Blanchard
2009-09-28 8:07 ` Benjamin Herrenschmidt
2009-09-28 9:13 ` Michael Ellerman [this message]
2009-09-30 6:01 ` Michael Neuling
2009-09-30 20:30 ` Benjamin Herrenschmidt
2009-10-01 5:06 ` Michael Neuling
2009-10-01 5:09 ` Michael Neuling
2009-09-30 13:57 ` Arnd Bergmann
2009-10-01 3:36 ` Michael Ellerman
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=1254129208.5959.7.camel@concordia \
--to=michael@ellerman.id.au \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.ozlabs.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;
as well as URLs for NNTP newsgroup(s).