linux-kernel - Re: [PATCH 4/6] watchdog: Boot-disable by default on full dynticks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 14 Jun 2013 05:26:08 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	anish singh <anish198519851985@...il.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Don Zickus <dzickus@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Li Zhong <zhong@...ux.vnet.ibm.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Subject: Re: [PATCH 4/6] watchdog: Boot-disable by default on full dynticks

On Fri, Jun 14, 2013 at 09:47:31AM +0530, anish singh wrote:
> On Thu, Jun 13, 2013 at 10:46 PM, Steven Rostedt <rostedt@...dmis.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
Steven mentioned.

							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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/