Announcement

Collapse
No announcement yet.

CONFIG_NO_HZ_FULL Pulled Into Linux 3.10 Kernel

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

  • #11
    Originally posted by Wildfire View Post
    Whether or not a particular option is used depends on the distro/target audience. As the article mentions this option is currently experimental (the kernel has always contained a few of those, you'll only see them if you tick "show experimental stuff"). Unless this option offers improvements for the average user, most distros will keep clear anyway. My guess: You'll not see this option in action any time soon, unless you build your own kernel.
    The experimental point isn't actually true anymore Wildfire, they recently (month ago?) dropped the "Experimental" tickbox since code would improve but no one would ever go and change what heading it was under in the config, thus leading to everyone having to load "Experimental" features ANYWAY. Now experimental features are mixed in with the usual ones except they are supposed to begin with " *EXPERIMENTAL!* " Until such as time the maintainers feel the code is of sufficient quality to drop said warning.

    I think, but am not positive, that until the change BTRFS was still mixed in under "Experimental" and yet all distros shipped it as an available option.
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #12
      Originally posted by Ericg View Post
      The experimental point isn't actually true anymore Wildfire, they recently (month ago?) dropped the "Experimental" tickbox since code would improve but no one would ever go and change what heading it was under in the config, thus leading to everyone having to load "Experimental" features ANYWAY. Now experimental features are mixed in with the usual ones except they are supposed to begin with " *EXPERIMENTAL!* " Until such as time the maintainers feel the code is of sufficient quality to drop said warning.

      I think, but am not positive, that until the change BTRFS was still mixed in under "Experimental" and yet all distros shipped it as an available option.
      My main point is that the kernel does and always has contained experimental code. Whether it's hidden by default or not isn't all that important, as long as it's clearly marked as such (that is, unless people forget to add/remove the tag).

      Also, there's a small difference between this option and BTRFS. Enabling BTRFS in the kernel just means the kernel supports it, but you're not automatically using it. When the kernel is modular it's not even loaded unless you're using a file system with BTRFS. To do so you'll have to explicitly select BTRFS during installation, which the average user won't (since they'll just use the default fs and/or partition layout). Thus enabling it doesn't really hurt anyone, but it's beneficial to users who want to try the new fs without having to rebuild the kernel to do so.

      The same is not true with CONFIG_NO_HZ_FULL since it's an either-or decision. Unless it has some real benefits for the average user I doubt it'll be selected over CONFIG_NO_HZ. If you want to try it out you'll have to rebuild your kernel anyway (or the distro just might offer an alternative kernel).
      Last edited by Wildfire; 06 May 2013, 04:18 PM.

      Comment


      • #13
        Michael missed this bit, but later in the thread Ingo explained why he thought Linus was willing to buy into the no_hz thing at all

        I think Linus might have referred to my 'future plans' entry:

        | Future plans:
        |
        | - there's ongoing work to reduce 1Hz to 0Hz, to essentially shut
        | off the periodic tick altogether when there's a single busy task on a
        | CPU. We'd first like 1 Hz to be exposed more widely before we go for
        | the 0 Hz target though.
        |
        | - once we reach 0 Hz we can and remove the periodic tick assumption from
        | nr_running>=2 as well, by essentially interrupting busy tasks only as
        | frequently as the sched_latency constraints require us to do - once
        | every 4-40 msecs, depending on nr_running.

        and indicated that in practice desktop and developer workload will see the
        full win from reduced HZ only once we implement those two points and
        extend the scope of dynticks even more and make HZ truly variable
        regardless of rq->nr_running
        Linus responded that it was these future plans, not the HPC benchmarks, which he considers utterly useless, that made him decide to support the merge.

        Comment


        • #14
          Originally posted by Rexilion View Post
          Many regressions, few gains.
          But we can still choose CONFIG_NO_HZ_IDLE over CONFIG_NO_HZ_FULL, right?
          Where can I find more information about those regressions?

          Comment


          • #15
            Originally posted by ypnos View Post
            This feature is a major evolutionary step in modern operating system kernel development.
            Please explain yourself since your opinion seems to be the polar opposite of Linus's.

            Comment


            • #16
              Originally posted by varikonniemi View Post
              Please explain yourself since your opinion seems to be the polar opposite of Linus's.
              Well, Jonathan Corbet compares it to the big kernel lock here: http://lwn.net/SubscriberLink/549580/82983789866b5fad/

              I also don't see how Linus' opinion is the polar opposite. All he claims is that the HPC use case is not worth the trouble. But we are just at the beginning. If Linus would not see the potential, he would not pull the feature.

              Comment

              Working...
              X