Re: New (now current development process)

[Linus Torvalds <torvalds@osdl.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/