Proposed: A Tainted Performance State For The Linux Kernel

[phoronix]

Phoronix: Proposed: A Tainted Performance State For The Linux Kernel

Similar to the kernel states of having a tainted kernel for using binary blob kernel modules or unsigned modules, a new tainting method has been proposed for warning the user about potentially adverse kernel performance...

http://www.phoronix.com/vr.php?view=MTc2ODA

[rohcQaH]

Is PTS going to honor that message and refuse benchmarking if it's found? There's been a few articles reporting "regressions" in debug-kernels in the past, so I guess it'd be useful.

[uid313]

make menuconfig

Or a notice in "make xconfig" or "make menuconfig" on the entries that impair performance.

Like "Beware this option negatively affects performance".
So that you can know which options impair performance when configuring the kernel.

[sdack]

This seems to be a rather useless feature and can only be helpful to the inexperienced kernel hackers, who do not yet know what they are doing. Everyone else, who forgets about which kernel options are turned on, will forget to remember to check the messages, too. And even when turned on might the message flash too fast across the screen or needs to be searched for among all the many other kernel messages. What is the real gain then? If you think about it and think it all the way through then it is a rather dumb feature. It seems like one of those inventions one starts to come up with after doing a nonstop-48h-without-sleep hack session. Those who are serious about kernel benchmarking will already save the configuration with their benchmark and actively compare it to make sure they have the right kernel and that their tests are reproducible. There are far more options than the patch suggests that have an affect on performance, even the choice of the filesystem has got an effect on it. Does one then get a warning for using the "wrong" filesystem? I rather hope not.

TL;DR: It is at best a feature for kernel newbies. Pros will not need it, nor should they rely on it.

[darkbasic]

Is PTS going to honor that message and refuse benchmarking if it's found? There's been a few articles reporting "regressions" in debug-kernels in the past, so I guess it'd be useful.

+1 stupid character limit

[rice_nine]

Is PTS going to honor that message and refuse benchmarking if it's found? There's been a few articles reporting "regressions" in debug-kernels in the past, so I guess it'd be useful.

-1, even though it doesn't affect me (not a PTS user), only because of this: PTS could then no longer be used to deliberately demonstrate or characterize the degradation caused by any of the tainted options. I feel it's ok to leave warning labels on everything, and simply echoing the warning in PTS sounds far better than that sort of 'failsafe'. Everyone who builds a kernel has all those nice "enabling this if you don't need it will only increase your kernel by 482KB but will not affect performance" messages, right with the option, which is where the warnings make sense to me. Maybe they're not perfectly clear and maybe they're not on every help text where they would belong, but there you go-- just improve the docs if you think you know what's missing, and let people do their thing. FWIW, I've been running 'make menuconfig' and reading the help on new items and building kernels for everything since around 2003 when I moved into Slackware for a while.

TL;DR: It is at best a feature for kernel newbies. Pros will not need it, nor should they rely on it.

+1 even though I'm no pro

[schmidtbag]

TL;DR: It is at best a feature for kernel newbies. Pros will not need it, nor should they rely on it.

Everyone has to start somewhere. Adding this is hardly going to bloat the kernel and can make a big difference.

[sdack]

Everyone has to start somewhere. Adding this is hardly going to bloat the kernel and can make a big difference.

Of course does everyone start somewhere, but should this be the Linux kernel??

I do not see why the kernel needs newbie features. The kernel supports holding a copy of the config file within itself. Everything else should be left to user-land, which is the most common strategy. When then someone cannot keep track of the debugging options, which makes me think he cannot keep track of what these do either, then he is doing it wrong.

[bjoswald]

Of course does everyone start somewhere, but should this be the Linux kernel??

I do not see why the kernel needs newbie features. The kernel supports holding a copy of the config file within itself. Everything else should be left to user-land, which is the most common strategy. When then someone cannot keep track of the debugging options, which makes me think he cannot keep track of what these do either, then he is doing it wrong.

If Linux had adequate documentation, this wouldn't be necessary. Getting others to actually read said documentation is a whole other issue, however.

[schmidtbag]

If Linux had adequate documentation, this wouldn't be necessary. Getting others to actually read said documentation is a whole other issue, however.

That's true - the lack of adequate documentation is exactly why I don't attempt to make my own modifications to the kernel myself, and why I never bother to compile it myself.