Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752831AbdGSGMj (ORCPT ); Wed, 19 Jul 2017 02:12:39 -0400 Received: from mga01.intel.com ([192.55.52.88]:45749 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752708AbdGSGMg (ORCPT ); Wed, 19 Jul 2017 02:12:36 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,379,1496127600"; d="scan'208";a="126784732" 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: <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> <20170718065926.GP3441@tassilo.jf.intel.com> From: "Li, Aubrey" Message-ID: <348019f4-85ae-ba91-3fce-9886533e8d22@linux.intel.com> Date: Wed, 19 Jul 2017 14:12:32 +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: 1949 Lines: 46 On 2017/7/18 15:19, Thomas Gleixner wrote: > On Mon, 17 Jul 2017, Andi Kleen wrote: >> On Tue, Jul 18, 2017 at 08:43:53AM +0200, 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. >> >> You didn't look at Aubrey's data? >> >> There are some unavoidable slow operations in the current path -- e.g. >> reprograming the timer for NOHZ. But we don't need that for really >> short idle periods, because as you pointed out they never get woken >> up by the tick. >> >> Similar for other things like RCU. >> >> I don't see how you can avoid that other than without a fast path mechanism. > > You can very well avoid it by taking the irq timings or whatever other > information into account for the NOHZ decision. > If I read the source correctly, irq timing statistics computation happens at idle time. Sadly, this is what Andi Kleen worried about. People keep putting more and more slow stuff in idle path, not realizing it could be a critical path. /* * The computation happens at idle time. When the CPU is not idle, the * interrupts' timestamps are stored in the circular buffer, when the * CPU goes idle and this routine is called, all the buffer's values * are injected in the statistical model continuing to extend the * statistics from the previous busy-idle cycle. */ Thanks, -Aubrey