lkml.org 
[lkml]   [2013]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 4/6] watchdog: Boot-disable by default on full dynticks
    From
    On Thu, Jun 13, 2013 at 10:46 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
    > On Thu, 2013-06-13 at 21:51 +0530, anish singh wrote:
    >
    >> > The concept behind full dynamic ticks is very easy. When you set a given
    >> > CPU(s) to dynamic tick, when it only has a single task scheduled on that
    >> > CPU, it disables the periodic tick. This removes essentially *all*
    >>
    >> Documentation/timers/highres.txt states that
    >> hrtimer_stop_sched_tick() is called when a CPU goes into idle state.Would
    >> you mind elaborating "single task scheduled on that CPU"?
    >> I am bit new to this so please excuse me if the question is too basic.
    >
    > That's the old CONFIG_NO_HZ, which only disables the tick on idle. What
    > we are working on is to also disable the tick when there's only one task
    > running on a given CPU. Why have as schedule tick when there's nothing
    > to schedule?
    >
    > 3.10 now has new config options:
    >
    > CONFIG_NO_HZ_PERIODIC - which is NO_HZ disabled
    > (the old # CONFIG_NO_HZ not set)
    >
    > CONFIG_NO_HZ_IDLE - which is what CONFIG_NO_HZ use to be.
    >
    > Note, CONFIG_NO_HZ still exists and if set, will make CONFIG_NO_HZ_IDLE
    > the default. This was to keep the same configuration for people who
    > update their kernel and run make oldconfig.
    >
    > Then there's the new:
    >
    > CONFIG_NO_HZ_FULL - this enables CONFIG_NO_HZ_IDLE plus adds the new
    > feature with disabling the tick when only one task is running on a given
    > CPU.

    Thanks and some more explanation in below documents.
    Documentation/timers/NO_HZ.txt
    Documentation/timers/highres.txt
    >
    >
    >> > latency from the kernel! That is, if the task is doing some complex
    >> > calculations, it wont be interrupted for kernel maintenance. A lot of
    >> > Red Hat customers would love to have this feature. It allows for
    >> > extremely low latency actions even without a real-time kernel. Heck, it
    >> > works without even kernel preemption.
    >> >
    >> > Now removing the periodic tick is not a trivial task, and this is where
    >>
    >> You mean getting rid of period ticks in the kernel code is not easy as there
    >> are many features such as perf is dependent on it right and that is why
    >> instead of completely removing periodic ticks we just set the periodic tick
    >> to happen at 1HZ instead of CONFIG_HZ value?
    >
    > IIRC, the reason for moving to 1 HZ is so that the scheduler doesn't get
    > confused with overflows. It still needs to handle time keeping for
    "overflows" meaning the tick happening at 1HZ?
    However as I see here in this patch http://lwn.net/Articles/549592/ -
    you have plans to move it to 0Hz then how does scheduler cope
    with this?Does it not need this information to schedule a different
    task when the current task on "adaptive-ticks CPU" is done?

    Anyway doesn't "future works" should be part of No-hz.txt document?
    > managing how to schedule tasks according to CFS.
    >
    > Everything else shouldn't depend on the tick... period.
    >
    > -- Steve
    >
    >> > all our issues come from. In fact, we can not even completely remove the
    >> > tick yet, we just move it to 1 HZ instead of whatever the CONFIG_HZ is
    >> > set to. We have to handle everything that depends on that tick, which
    >> > includes perf, among other things.
    >> >
    >
    >


    \
     
     \ /
      Last update: 2013-06-14 07:01    [W:5.893 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site