Message-ID: <1371138491.9844.288.camel@gandalf.local.home>
Date:	Thu, 13 Jun 2013 11:48:11 -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 Thu, 2013-06-13 at 11:20 -0400, Don Zickus wrote:

> I don't know enough about how full dynticks work to even present a
> solution.  But currently I was working with the Red Hat performance team
> to enhance perf to help our customers diagnose performance problems
> easier.
> 
> My fear is anyone who uses full dynticks and has issues, can't use perf to
> help diagnose their problems because it will change the dynamics of the
> problem.  And with the current huge drop in performance in cpu_idle (as
> compared to RHEL-6's 2.6.32 kernel) due to what seems to be miscalculated
> c-states, one might have a hard time evaluating if full dynticks is doing
> the right thing or not.

This needs to be fixed, but not for 3.11. Although, you can still use
ftrace to diagnose it.

> 
> Then again perhaps full dynticks isn't useful for distros like RHEL.

It will be very useful for RHEL. But its still very new, and I wouldn't
recommend using it in a production environment yet. There's still a few
issues that need to be worked out, including this one. When the issues
are fixed, then RHEL and other distributions will definitely want to
enable this.

> 
> That's why I was hoping to solve the underlying problem as opposed to
> accepting patches like this which work around the symptoms.

For now it's just to get things working as people expect it to. First
impressions are very important, and if someone enables it and sees it
makes no difference, they may from then on never trust it. The way to
handle that is to make sure it works when enabled, even if it disables
some other cool features. But as I said, it shouldn't be used in
production quite yet.

> 
> Again, my knowledge of full dynticks is poor, so I have almost no idea of
> the complexities surrounding the problem and how hard it is to even solve
> it.

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
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
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.

-- 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