putting fedora on a (memory) diet... some suggestions for the kernel config

Don Dutile ddutile at redhat.com
Wed Dec 13 17:36:49 UTC 2006


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...




More information about the fedora-devel-list mailing list