Features no excuse

Posted Oct 5, 2009 10:34 UTC (Mon) by eru (subscriber, #2753)
In reply to: LinuxCon: Kernel roundtable covers more than just bloat by Los__D
Parent article: LinuxCon: Kernel roundtable covers more than just bloat

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 (guest, #23785) [Link] (1 responses)

[[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.
Sure if you have an option to remove the code from the kernel at compilation time, then this issue shouldn't happen.. So which configuration did Intel benchmark?

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 (guest, #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 (guest, #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.