Thanks Paul & Steve for replying. On Fri, Jun 14, 2013 at 5:56 PM, Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: > On Fri, Jun 14, 2013 at 09:47:31AM +0530, anish singh wrote: >> On Thu, Jun 13, 2013 at 10:46 PM, Steven Rostedt <rost...@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? > > When the current task completed, it will enter the kernel, allowing > the scheduler to take over. > > If a second task awakens or is created, there will either be some sort > of interrupt to the CPU itself, or to some other CPU, and this other > CPU will IPI the first CPU. Either way, the scheduler gains control > when it needs it -- but avoids continually interrupting the task. > >> Anyway doesn't "future works" should be part of No-hz.txt document? > > It does, please see the very last bullet of the document: > > o Some process-handling operations still require the occasional > scheduling-clock tick. These operations include calculating CPU > load, maintaining sched average, computing CFS entity vruntime, > computing avenrun, and carrying out load balancing. They are > currently accommodated by scheduling-clock tick every second > or so. On-going work will eliminate the need even for these > infrequent scheduling-clock ticks. > > Here, "the occasional scheduling-clock tick" is the 1Hz tick that
May I know why we zeroed in on 1Hz? Is there any logical reason or just because it is above 0Hz? > > Thanx, Paul > >> > 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. >> >> > >> > >> > >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
