Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751413AbdGRG4w (ORCPT ); Tue, 18 Jul 2017 02:56:52 -0400 Received: from mga06.intel.com ([134.134.136.31]:26861 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026AbdGRG4u (ORCPT ); Tue, 18 Jul 2017 02:56:50 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,377,1496127600"; d="scan'208";a="126335539" Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods To: Thomas Gleixner , Andi Kleen Cc: Peter Zijlstra , Frederic Weisbecker , Christoph Lameter , Aubrey Li , len.brown@intel.com, rjw@rjwysocki.net, tim.c.chen@linux.intel.com, arjan@linux.intel.com, paulmck@linux.vnet.ibm.com, yang.zhang.wz@gmail.com, x86@kernel.org, linux-kernel@vger.kernel.org, daniel.lezcano@linaro.org References: <20170713145311.z4zxlyd2dospeoqg@hirez.programming.kicks-ass.net> <4a577bd6-20b1-abb6-2153-f9870f0a721e@linux.intel.com> <20170713182820.sn3fjitnd3mca27p@hirez.programming.kicks-ass.net> <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> From: "Li, Aubrey" Message-ID: Date: Tue, 18 Jul 2017 14:56:47 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2055 Lines: 46 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) 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