Arjan van de Ven wrote: > On Wed, 2006-12-13 at 11:07 -0500, Don Dutile wrote: >> Arjan van de Ven wrote: >>> Looking at kernel memory use (based on 2.6.19 with a fedora config), >>> there's some not that hard ways to gain quite a bit of memory back. >>> >>> Most important is CONFIG_NR_CPUS, right now that is set to 255 for >>> everyone; this value is used for scaling a LOT of things in the kernel, >>> and the sad thing is it's not even possible today to get a 255 >>> core/processor machine (you run out of apic ids well before you get that >>> far). >>> >>> Setting CONFIG_NR_CPUS to 64 (which is still huge, even 16 would be more >>> than 99.99999% of the people who use fedora will ever use) will save >>> >> The proper solution: kmalloc-based, per-cpu structs; wire to gs(or is it cs) reg >> like pda is, if performance is an issue. then you only get what you need. > > except if you still do it for each cpu. > And not all of these are per cpu things at all; they just SCALE with the > number of cpus. That's not the same. > ANd the IRQ stuff needs to be there long before kmalloc works.. it's not > that easy. Yeah, I'll agree this area needs a re-design for scaling as well! ;-) > > >> Pls! Size it based on memory: on small mem footprints (256MB), make it 32K; >> large memory footprints (1G and above) make it 512KB! (a la "I like to make >> it big for debugging" Jeremy). > > logbuf needs to work REAL early, before dynamic allocators work. did this in Tru64-UNIX -- steal memory during early boot, when you know size of memory, before kmalloc in place; it wasn't that tough to do (8 years ago). >> better yet: put tools in place that warn when a function uses X-amt of stack, >> and analyze those functions/modules for lower stack utilization. > > like make checkstack ? been there done that 3 years ago ;) > sounds like we need a time machine... -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
