Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755868AbbKROVf (ORCPT ); Wed, 18 Nov 2015 09:21:35 -0500 Received: from mga02.intel.com ([134.134.136.20]:41766 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752859AbbKROVe (ORCPT ); Wed, 18 Nov 2015 09:21:34 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,313,1444719600"; d="scan'208";a="688484751" Subject: Re: [PATCH 3/4] sched: introduce synchronized idle injection To: Ingo Molnar , Jacob Pan References: <1447444387-23525-1-git-send-email-jacob.jun.pan@linux.intel.com> <1447444387-23525-4-git-send-email-jacob.jun.pan@linux.intel.com> <20151118083622.GA25217@gmail.com> Cc: Peter Zijlstra , Ingo Molnar , Thomas Gleixner , John Stultz , LKML , Srinivas Pandruvada , Len Brown , Rafael Wysocki , Eduardo Valentin , Paul Turner From: Arjan van de Ven Message-ID: <564C88E7.4050907@linux.intel.com> Date: Wed, 18 Nov 2015 06:19:19 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151118083622.GA25217@gmail.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: 2471 Lines: 39 On 11/18/2015 12:36 AM, Ingo Molnar wrote: > > What will such throttling do to latencies, as observed by user-space tasks? What's > the typical expected frequency of the throttling frequency that you are targeting? for this to meaningfully reduce power consumption, deep system power states need to be reached, and for those to pay of, several milliseconds of idle are required. for hard realtime stuff that is obviously insane, but I would assume that for those cases your system is thermally fine. This only kicks in at the end of a "we're in thermal problems" path, which can happen both on clients (thin devices) as well as servers (airconditioning issues). The objective for this is to kick in before the hardware built-in protections kick in (which are power off/reboot depending on a bunch of things). The frequency of how often these 5 msec get injected depend on how deep the system is in trouble; and is zero if the system is not in trouble. The idea is that for the user it is better to inject several 5 msec intervals than it is to inject one longer period. You can compare this method to other ways of reducing thermal issues (like lowering cpu frequency), and in a typical setup, this is done after the benign of those methods are exhausted. Lowering frequency even lower is usually of a low efficiency (you need to lower the frequency a LOT to gain a little bit of power in the bottom parts of the frequency ranges), while this idle will not only put the CPU in low power, but will also put the system memory in low power and usually a big chunk of the rest of the SOC. In many client systems, memory power consumption is higher than CPU power consumption (and in big servers, it's also quite sizable), so there is a pretty hard limit of how much you can do on thermals if you're not also kicking some of the memory power savings. This means that to achieve a certain amount of reduction, the performance is impacted a lot less than the more drastic methods you would need on the cpu side, if possible at all. (stepping your 2 Ghz cpu down to 50Mhz may sound less evil than injecting 5msec of idle time, but in reality that is impacting user tasks a heck of a lot more than 5msec of not being scheduled) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/