Thread (9 messages) 9 messages, 5 authors, 2009-10-01

Re: 64bit kernel is huge

From: Michael Ellerman <hidden>
Date: 2009-09-28 09:13:28

On Mon, 2009-09-28 at 18:07 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2009-09-28 at 17:45 +1000, Anton Blanchard wrote:
quoted
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.
quoted
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help