| |||||||||||||
LinuxCon: Kernel roundtable covers more than just bloatLinuxCon: Kernel roundtable covers more than just bloatPosted Oct 2, 2009 18:09 UTC (Fri) by simonl (guest, #13603)In reply to: LinuxCon: Kernel roundtable covers more than just bloat by dowdle Parent article: LinuxCon: Kernel roundtable covers more than just bloat
The Moore's law reference stinks. It is a typical commercial vendor apologist view. Sorry, our software sucks, we know, but just buy faster hw and make up for our crap.
When you argue that way, you take no pride in your code. And pride is what built this kernel.
Maybe the kernel devs have become too employed. Too focused on solving customers' immediate needs, and having too little time to go hunt down whatever catches their attention, big or small, with no prospects to please a project manager.
But look what Apple just did in their latest release: Nothing spectacular, except cleaning up. Someone has had the guts to nack new features and focus on removal.
(Log in to post comments)
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 4, 2009 9:41 UTC (Sun) by Los__D (guest, #15263) [Link]
Features costs performance. Drops for no reason is, of course, a problem but tradeoffs will need to be made sometimes.
You could have a LIGHTNING FAST DOS box today. What good would it do you?
Features no excuse Posted Oct 5, 2009 10:34 UTC (Mon) by eru (subscriber, #2753) [Link] Features costs performance.But if you don't use the features, you should not need to pay the price! If I understand correctly, the slowdown has been seen in repeatable benchmarks that can be run on both old and new kernel versions. Therefore the benchmarked code certainly isn't using any new features, but it still gets slowed down. Not justifiable. You could have a LIGHTNING FAST DOS box today. What good would it do you? Bad comparison. MS-DOS always had severe problems that really did not have much to do with its small footprint. It was brain-damaged already on day one. An OS that does more or less what MS-DOS did, but in a sensible and stable way might still be useful.
Features no excuse Posted Oct 8, 2009 8:20 UTC (Thu) by renox (subscriber, #23785) [Link]
[[But if you don't use the features, you should not need to pay the price!
If I understand correctly, the slowdown has been seen in repeatable benchmarks that can be run on both old and new kernel versions. Therefore the benchmarked code certainly isn't using any new features, but it still gets slowed down. Not justifiable.]]
Linus referred to the icache footprint(size) of the kernel, if you add features, even when not used they increased the size of the generated code so they reduce the performance.
Without specific figures, it's difficult to know where the issue is, I wouldn't be surprised that SELinux or virtualisation are the culprit: these features seems quite invasive..
Features no excuse Posted Oct 8, 2009 9:03 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
adding SELinux defiantly slows things down, and if you run a benchmark on a system running a kernel compiled with SELinux you will get lower results than if you run the same benchmark on the same kernel without SELinux
so to not use the feature of SELinux you would compile a kernel without it.
the same thing goes for many fetures, turning them on at compile time increases the cache footprint and therefor slows the system, even if you don't use the feature. but you (usually) do have the option to not compile the code into the kernel to really avoid the runtime cost of them.
Features no excuse Posted Oct 8, 2009 9:10 UTC (Thu) by bersl2 (subscriber, #34928) [Link] But if you don't use the features, you should not need to pay the price! If I understand correctly, the slowdown has been seen in repeatable benchmarks that can be run on both old and new kernel versions. Therefore the benchmarked code certainly isn't using any new features, but it still gets slowed down. Not justifiable. Then configure out what you don't want already. Really, you think going with your distro's generic kernel is efficient? It doesn't take very long to find /proc/config* and take out some of the above-mentioned features that can't be modular. That, or yell at your distro, for the little good that will do.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 4, 2009 12:04 UTC (Sun) by fuhchee (subscriber, #40059) [Link]
"... Too focused on solving customers' immediate needs, and having too little time to go hunt down whatever catches their attention ..."
I suspect it's the other way around. Many customers care deeply about performance, and it is their vendors who must perform code-karate against this kind of "bloat" (slowdown). To justify each new thing, LKML rarely carries data beyond microbenchmarks.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 5, 2009 8:11 UTC (Mon) by cmccabe (guest, #60281) [Link]
> The Moore's law reference stinks. It is a typical commercial vendor
> apologist view. Sorry, our software sucks, we know, but just buy faster hw > and make up for our crap. > > When you argue that way, you take no pride in your code. And pride is what > built this kernel.
Well, maybe, you can have clean code that runs 12% slower, or you can have code that's #ifdef'ed to hell that runs at the old speed. In that case, which would you rather have?
Keep in mind, if you choose route #2, people in 2015 might use your name as a curse...
Obviously this is an oversimplification. But still, the point remains: don't criticize the code until you've seen it and understand the tradeoffs.
pride comes before a fall Posted Oct 14, 2009 9:52 UTC (Wed) by gvy (guest, #11981) [Link]
> And pride is what built this kernel.
I hope *not*.
|
|||||||||||||