From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751470Ab3FNERe (ORCPT ); Fri, 14 Jun 2013 00:17:34 -0400 Received: from mail-we0-f171.google.com ([74.125.82.171]:62512 "EHLO mail-we0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832Ab3FNERc (ORCPT ); Fri, 14 Jun 2013 00:17:32 -0400 MIME-Version: 1.0 In-Reply-To: <1371143779.9844.297.camel@gandalf.local.home> References: <1371045758-5296-1-git-send-email-fweisbec@gmail.com> <1371045758-5296-5-git-send-email-fweisbec@gmail.com> <20130612170316.GO133453@redhat.com> <20130613131057.GA15997@somewhere> <20130613140207.GW133453@redhat.com> <20130613142210.GD16339@somewhere> <20130613144515.GX133453@redhat.com> <20130613145601.GE16339@somewhere> <20130613152059.GA133453@redhat.com> <1371138491.9844.288.camel@gandalf.local.home> <1371143779.9844.297.camel@gandalf.local.home> Date: Fri, 14 Jun 2013 09:47:31 +0530 Message-ID: Subject: Re: [PATCH 4/6] watchdog: Boot-disable by default on full dynticks From: anish singh To: Steven Rostedt Cc: Don Zickus , Frederic Weisbecker , Peter Zijlstra , LKML , "Paul E. McKenney" , Ingo Molnar , Andrew Morton , Thomas Gleixner , Li Zhong , "Srivatsa S. Bhat" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 13, 2013 at 10:46 PM, Steven Rostedt 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. >> > > >