Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751515AbdGRP3o (ORCPT ); Tue, 18 Jul 2017 11:29:44 -0400 Received: from mga01.intel.com ([192.55.52.88]:57394 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751415AbdGRP3m (ORCPT ); Tue, 18 Jul 2017 11:29:42 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,378,1496127600"; d="scan'208";a="109305704" Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods To: paulmck@linux.vnet.ibm.com, "Li, Aubrey" 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> <20170718152014.GB3981@linux.vnet.ibm.com> Cc: Thomas Gleixner , Andi Kleen , Peter Zijlstra , Frederic Weisbecker , Christoph Lameter , Aubrey Li , len.brown@intel.com, rjw@rjwysocki.net, tim.c.chen@linux.intel.com, yang.zhang.wz@gmail.com, x86@kernel.org, linux-kernel@vger.kernel.org, daniel.lezcano@linaro.org From: Arjan van de Ven Message-ID: <72182f86-261b-1952-b1c2-864f43e15b0c@linux.intel.com> Date: Tue, 18 Jul 2017 08:29:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170718152014.GB3981@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1355 Lines: 27 On 7/18/2017 8:20 AM, Paul E. McKenney wrote: > 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 the most obvious way to do this (for me, maybe I'm naive) is to add another C state, lets call it "C1-lite" with its own thresholds and power levels etc, and just let that be picked naturally based on the heuristics. (if we want to improve the heuristics, that's fine and always welcome but that is completely orthogonal in my mind) this C1-lite would then skip some of the idle steps like the nohz logic. How we plumb that ... might end up being a flag or whatever, we'll figure that out easily. as long as "real C1" has a break even time that is appropriate compared to C1-lite, we'll only pick C1-lite for very very short idles like is desired... but we don't end up creating a parallel infra for picking states, that part just does not make sense to me tbh.... I have yet to see any reason why C1-lite couldn't be just another C-state for everything except the actual place where we do the "go idle" last bit of logic. (Also note that for extreme short idles, today we just spinloop (C0), so by this argument we should also do a C0-lite.. or make this C0 always the lite variant)