Date: Tue, 18 Jul 2017 08:20:14 -0700
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: "Li, Aubrey" <aubrey.li@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Andi Kleen <ak@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Christoph Lameter <cl@linux.com>, Aubrey Li <aubrey.li@intel.com>,
        len.brown@intel.com, rjw@rjwysocki.net, tim.c.chen@linux.intel.com,
        arjan@linux.intel.com, yang.zhang.wz@gmail.com, x86@kernel.org,
        linux-kernel@vger.kernel.org, daniel.lezcano@linaro.org
Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods
Reply-To: paulmck@linux.vnet.ibm.com
References: <31170ac6-9db1-f0b8-4841-f1661c8ed6e1@linux.intel.com>
 <20170714153818.pjauqxebxyhs6ljp@hirez.programming.kicks-ass.net>
 <20170714155356.GH3441@tassilo.jf.intel.com>
 <20170714160648.tg2u6eo2id6gmnjz@hirez.programming.kicks-ass.net>
 <20170714162619.GJ3441@tassilo.jf.intel.com>
 <20170717192309.ubn5muvc3u7htuaw@hirez.programming.kicks-ass.net>
 <34371ef8-b8bc-d2bf-93de-3fccd6beb032@linux.intel.com>
 <20170718044521.GO3441@tassilo.jf.intel.com>
 <alpine.DEB.2.20.1707180841290.1945@nanos>
 <f0ca590c-ea67-c17a-b0b9-13940150f1ae@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f0ca590c-ea67-c17a-b0b9-13940150f1ae@linux.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20170718152014.GB3981@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2358
Lines: 53

On Tue, Jul 18, 2017 at 02:56:47PM +0800, Li, Aubrey wrote:
> On 2017/7/18 14:43, Thomas Gleixner wrote:
> > On Mon, 17 Jul 2017, Andi Kleen wrote:
> > 
> >>> We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if
> >>> it's better than menu governor.
> >>
> >> I still would like to see how the fast path without the C1 heuristic works.
> >>
> >> Fast pathing is a different concept from a better predictor. IMHO we need
> >> both, but the first is likely lower hanging fruit.
> > 
> > Hacking something on the side is always the lower hanging fruit as it
> > avoids solving the hard problems. As Peter said already, that's not going
> > to happen unless there is a real technical reason why the general path
> > cannot be fixed. So far there is no proof for that.
> > 
> Let me try to make a summary, please correct me if I was wrong.
> 
> 1) for quiet_vmstat, we are agreed to move to another place where tick is
> really stopped.
> 
> 2) for rcu idle enter/exit, I measured the details which Paul provided, and
> the result matches with what I have measured before, nothing notable found.
> But it still makes more sense if we can make rcu idle enter/exit hooked with
> tick off. (it's possible other workloads behave differently)

Again, assuming that RCU is informed of CPUs in the kernel, regardless
of whether or not the tick is on that that point in time.

							Thanx, Paul

> 3) for tick nohz idle, we want to skip if the coming idle is short. If we can
> skip the tick nohz idle, we then skip all the items depending on it. But, there
> are two hard points:
> 
> 3.1) how to compute the period of the coming idle. My current proposal is to
> use two factors in the current idle menu governor. There are two possible
> options from Peter and Thomas, the one is to use scheduler idle estimate, which
> is task activity based, the other is to use the statistics generated from irq
> timings work.
> 
> 3.2) how to determine if the idle is short or long. My current proposal is to
> use a tunable value via /sys, while Peter prefers an auto-adjust mechanism. I
> didn't get the details of an auto-adjust mechanism yet
> 
> 4) for idle loop, my proposal introduces a simple one to use default idle
> routine directly, while Peter and Thomas suggest we fix c-state selection
> in the existing idle path.
> 
> Thanks,
> -Aubrey
>