Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: CONFIG_NO_HZ_FULL Pulled Into Linux 3.10 Kernel

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,643

    Default CONFIG_NO_HZ_FULL Pulled Into Linux 3.10 Kernel

    Phoronix: CONFIG_NO_HZ_FULL Pulled Into Linux 3.10 Kernel

    Support for "full dynticks" has been accepted into the mainline Linux 3.10 kernel...

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

  2. #2
    Join Date
    Dec 2012
    Posts
    457

    Default

    Three cycles of preparing work and finally a request for a pull containing relatively untested patches.

    So I haven't actually found a real load where any of this makes a noticeable *difference*.
    Quite the risk if you ask me...

  3. #3
    Join Date
    May 2008
    Posts
    98

    Default

    Quote Originally Posted by Rexilion View Post
    Three cycles of preparing work and finally a request for a pull containing relatively untested patches.



    Quite the risk if you ask me...
    Did someone say that you had to configure your kernel using it? What's so dangerous about it? I'm sure all of the 'stable' distros are going to stay away for a couple years anyway.

  4. #4
    Join Date
    Dec 2012
    Posts
    457

    Default

    Quote Originally Posted by Vash63 View Post
    Did someone say that you had to configure your kernel using it?
    No, did I mention that?

    Quote Originally Posted by Vash63 View Post
    What's so dangerous about it?
    Many regressions, few gains.

    Quote Originally Posted by Vash63 View Post
    I'm sure all of the 'stable' distros are going to stay away for a couple years anyway.
    Causing less testing coverage since there are now multiple ways to configure a single kernel.

    Just my opinion though.

  5. #5
    Join Date
    Feb 2010
    Posts
    11

    Default

    This feature is a major evolutionary step in modern operating system kernel development.

    I am happy to see that the Linux kernel developers embrace new technologies. We don't need a copycat kernel just as well as we don't need a copycat desktop environment. As was said erlier, the common user of the kernel is not affected at all by introducing this new feature until benefits for the general usage will surface and regressions are ruled out.

  6. #6
    Join Date
    Dec 2011
    Posts
    2,028

    Default Asynchronous CPU?

    Would this be useful on a clockless asynchronous CPU?

    I wish there were more asynchronous processors on the market, it seems like an interesting idea...

  7. #7
    Join Date
    Jan 2012
    Posts
    180

    Default

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

  8. #8
    Join Date
    Feb 2012
    Posts
    66

    Default

    Quote Originally Posted by Rexilion View Post
    Causing less testing coverage since there are now multiple ways to configure a single kernel.

    Just my opinion though.
    Last time I built a kernel, there were thousands of configuration options One more is hardly gonna hurt...

    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.

    Quote Originally Posted by uid313 View Post
    Would this be useful on a clockless asynchronous CPU?
    The kernel's ticks and the CPU's clock rate are not related. A kernel that wakes up periodically potentially uses more power, whether the CPU is synchronous or asynchronous. Also, by "more" you mean "any relevant to the average user at all", right?

  9. #9
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,877

    Default

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

  10. #10
    Join Date
    Jan 2009
    Posts
    1,378

    Default

    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.

Posting Permissions

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