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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
