On Wed, Dec 13, 2006 at 11:56:33AM +0100, Arjan van de Ven wrote: > 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 > ... > total 2403839 > > this alone saves 2.4Mb of memory in *static* buffers! Add a bunch more > in smaller buffers and all dynamic kernel allocations and it'll be > closer to 3Mb.. Easy gain right there. That's definitly worthwhile. I'll make that change for the next FC5/FC6 updates as well as devel. In part this ended up so high because we wanted to see if there were any problems that needed to be fixed. Fixing this stuff now is a lot easier than fixing it post-RHEL5. It's entirely feasible that 256-way CPUs may be around before RHEL5 reaches EOL, (even if they do need apic.c changes etc). > Another one is __log_buf; this is currently 128Kb. Arguably it's > important for debugging to get 128Kb of dmesg info, but I wonder if 64Kb > would be enough as well, it's another easy save by setting > CONFIG_LOG_BUF_SHIFT to 16. As others mentioned, this is a bit of a downside, especially on kernels with lockdep enabled for eg, where the ring buffer gets spent really quickly ;) > A third one is disabling CPU hotplug. CPU hotplug keeps quite a bit of > code in the kernel, that otherwise is boot-time only and gets evicted > right after boot..... Needed for software suspend on SMP. > I don't know what Dave will pick for CONFIG_STACK_PROTECTOR_ALL; I would > suggest to turn this off (while enabling the normal > CONFIG_STACK_PROTECTOR); _ALL doesn't add much if any security while it > creates bigger and slower code everywhere. (The difference is that _ALL > forces the canary on every function, while the normal setting only > forces it for functions with buffers on the stack) Hrmm.. $ grep CONFIG_STACK_PROTECTOR kernel-2.6.19/linux-2.6.19.noarch/configs/* $ Dave -- http://www.codemonkey.org.uk -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
