Announcement

Collapse
No announcement yet.

Proposed: A Tainted Performance State For The Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          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
          ## VGA ##
          AMD: X1950XTX, HD3870, HD5870
          Intel: GMA45, HD3000 (Core i5 2500K)

          Comment


          • #6
            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.

            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

            Comment


            • #7
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    Originally posted by bjoswald View Post
                    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.

                    Comment


                    • #11
                      Originally posted by bjoswald View Post
                      If Linux had adequate documentation, this wouldn't be necessary. Getting others to actually read said documentation is a whole other issue, however.
                      When your problem is with the documentation, then you fix the documentation and do not start with adding another option. This does not require an explanation. And when the existing documentation is not enough to comprehend the code and the code itself is not understood then it is best to stay away from the kernel, because at some point do you need to realize that there is not always someone around to hold your hand. If you want the kernel to be a playground for new programmers then you will have to get active yourself and make it so and not demand the pros to do it for you. That said, I cannot see why one would want to have newbies writing kernel code.

                      Back on the topic: what could be done is to collect the options in question into a group of their own and so that these can be turned off in one (disabling the group means disabling all the options within the group). This already exists and is being done with several options. What it does not need is new kernel code to tell you that you did something wrong in your configuration.

                      Comment


                      • #12
                        The original TAINTED warning is not for the user, they should be aware of what binary blob kernel modules they have, that warning is for the developers investigating crashes reported by such users.
                        The same way this is not necessarily for the user doing the benchmark, though it might help, but for the developer investigating the reported regression.
                        Does it make sense now?

                        Comment

                        Working...
                        X