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

Re: 64bit kernel is huge

From: Arnd Bergmann <arnd@arndb.de>
Date: 2009-09-30 14:02:57

On Monday 28 September 2009, Anton Blanchard wrote:
262144  kstat_irqs_all
131072  irq_desc
16384   irq_stat

Could we dynamically allocate our irq structures?
There were patches floating around for that a few years ago,
but I haven't seen anyone working on it since.
 
131072  lppaca
65536   paca

I think we've attacked these before, not sure if there is anything left
we can trim.
well, it essentially comes down to CONFIG_NR_CPUS. If you build with NR_CPUS=4,
this is really small.
 
131072  __log_buf

Looks like we can dynamically allocate a large log buf at runtime. Perhaps
we should default to a small log_buf and grow it at boot based on machine size
(eg max cpus).
I like the idea of being able to very easily find the log buffer in
dump files or in hw debuggers for bringup, but it's probably not
worth it for production systems. A config option might be nice.
101160  powerpc_opcodes

xmon instruction disassembly. I'd probably prefer to cut off my right hand and
debug one handed before losing this though.
This should be very compressible though, which will help binary size, but not
runtime memory footprint.
77452   _fw_acenic_tg2_bin_bin

We could probably change acenic to be a module, 
CONFIG_FIRMWARE_IN_KERNEL ?
17784   ioctl_start
I have a patch for this one that I need to submit some day.

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