Results 1 to 10 of 12

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

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,400

    Default Proposed: A Tainted Performance State For The Linux Kernel

    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

  2. #2
    Join Date
    Nov 2008
    Posts
    780

    Default

    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.

  3. #3
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    984

    Default

    Quote Originally Posted by rohcQaH View Post
    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

  4. #4
    Join Date
    Apr 2014
    Location
    Ohio
    Posts
    30

    Default

    Quote Originally Posted by rohcQaH View Post
    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.

    Quote Originally Posted by sdack View Post
    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

  5. #5
    Join Date
    Dec 2011
    Posts
    2,157

    Default 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.

  6. #6
    Join Date
    Mar 2011
    Posts
    230

    Default

    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.

  7. #7
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,443

    Default

    Quote Originally Posted by sdack View Post
    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.

  8. #8
    Join Date
    Mar 2011
    Posts
    230

    Default

    Quote Originally Posted by schmidtbag View Post
    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.

  9. #9
    Join Date
    Aug 2014
    Location
    Florida
    Posts
    7

    Default

    Quote Originally Posted by sdack View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •