[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1371224150.9844.327.camel@gandalf.local.home>
Date: Fri, 14 Jun 2013 11:35:50 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Don Zickus <dzickus@...hat.com>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
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>,
Anish Singh <anish198519851985@...il.com>
Subject: Re: [PATCH 4/6] watchdog: Boot-disable by default on full dynticks
On Fri, 2013-06-14 at 09:49 -0400, Don Zickus 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*
> > latency from the kernel! That is, if the task is doing some complex
>
> Including SMMi latency? ;-)
When you have SMI latencies, it's time to bitch at your vendor, not
us. ;-)
> >
> > Now removing the periodic tick is not a trivial task, and this is where
> > 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.
>
> Which part of perf is dependent on the tick? Just curious.
I'm not the one to answer this question, but it seems that it uses the
tick whenever perf is active. I had to disable watchdog when dynamic
tick was configured because it would permanently disable dynamic ticks
without letting the user know why. This is because watchdog uses perf
and enables it on boot and keeps it enabled.
-- Steve
--
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/
Powered by blists - more mailing lists