On Thu, 5 Dec 2002, Shane Helms wrote:
>
> Being curious, I was wondering, since we're not changing much in kernel core,
> and developement implies adding additional code and layers for security,
> enhancements and support for further hardware and etc.
> Does this not slow down the kernel ? or is the execution code still the same
> ??
Oh, some things do get slower. We try to avoid hitting the critical paths,
and supporting new hardware for example (which tends to be a large portion
of kernel development, even if it isn't as sexy as new features) doesn't
impact the rest of the kernel negatively at all.
What we'll probably see in 2.6.x for example, is that many microbenchmarks
show slight deprovement (fork() and execve() have become noticeably slower
due to the rmap patches), but to at least somewhat offset that we get much
nicer worst-case behaviour and better scalability.
And many things _can_ be done without throwing out old designs.
Implementation improvements are quite possible without trying to make
something totally new to the outside. That's how things like the dcache
come about, for example - keeping the standard old boring UNIX filesystem
approach, while internally caching it in new ways, improving performance
tremendously.
Not throwing out the baby with the bath-water doesn't mean that you cannot
improve the system. I'm only arguing against stupid people who think they
need a revolution to improve - most real improvements are evolutionary.
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/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:23 EST