|From:||Linus Torvalds <torvalds-AT-osdl.org>|
|To:||Roland Dreier <rolandd-AT-cisco.com>|
|Subject:||Re: New (now current development process)|
|Date:||Wed, 2 Nov 2005 07:54:04 -0800 (PST)|
|Cc:||Andrew Morton <akpm-AT-osdl.org>, zippel-AT-linux-m68k.org, ak-AT-suse.de, rmk+lkml-AT-arm.linux.org.uk, tony.luck-AT-gmail.com, paolo.ciarrocchi-AT-gmail.com, linux-kernel-AT-vger.kernel.org|
On Tue, 1 Nov 2005, Roland Dreier wrote: > > I think we're actually agreeing. My kmalloc/kzalloc patch is a cute > hack but magic tricks like that aren't going to shrink the kernel by > very much and it's probably not worth merging complications like that. Right. I don't like having too many ways of doing the same thing - it just confuses things and makes different people have different "coding styles" and makes things less maintainable (I think the perl philosophy is broken). > The way to a smaller kernel is for a lot of people to do a lot of hard > work and look at where we can trim fat. Yes. On the other hand, I do believe that bloat is a fact of life. Eventually somebody younger and leaver will come along and displace us. It's how things should be. We can (and should try to, of course) only delay the inevitable ;) The fact is, we do do more, and we're more complex. Out VM is a _lot_ more complex, and our VFS layer has grown a lot due to all the support it has for situations that simply weren't an issue before. And even when not used, that support is there. > For your last suggestion, maybe someone can automate running Andi's > bloat-o-meter? I think the hard part is maintaining comparable configs. Yes. And we should probably make -Os the default. Apparently Fedora already does that by just forcibly hacking the Kconfig files. With modern CPU's, instructions are almost "free". The real cost is in cache misses, and that tends to be doubly true of system software that tends to have a lot more cache misses than "normal" programs (because people try hard to batch up system calls like write etc, so by the time the kernel is called, the L1 cache is mostly flushed already - possibly the L2 too. And interrupts may be in the "fast path", but they'd sure as hell better not happen so often that they stay cached very well etc etc). So -Os probably performs better in real life, and likely only performs worse on micro-benchmarks. Sadly, micro-benchmarks are often very instructive in many other ways. Linus
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds