From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754104AbdKXRe0 (ORCPT ); Fri, 24 Nov 2017 12:34:26 -0500 Received: from cmta16.telus.net ([209.171.16.89]:49654 "EHLO cmta16.telus.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753889AbdKXReY (ORCPT ); Fri, 24 Nov 2017 12:34:24 -0500 X-Authority-Analysis: v=2.2 cv=S802+MkP c=1 sm=1 tr=0 a=zJWegnE7BH9C0Gl4FFgQyA==:117 a=zJWegnE7BH9C0Gl4FFgQyA==:17 a=Pyq9K9CWowscuQLKlpiwfMBGOR0=:19 a=IkcTkHD0fZMA:10 a=QyXUC8HyAAAA:8 a=HXCQWyq0h6lE2RO_S0cA:9 a=QEXdDO2ut3YA:10 From: "Doug Smythies" To: "'Thomas Ilsche'" , "'Len Brown'" Cc: , , , "'Len Brown'" References: <1d81edef71c936099f8bb9d16162f8e70fbe401c.1510212816.git.len.brown@intel.com> FMlqe98CNhCDuFMlsezUVk In-Reply-To: FMlqe98CNhCDuFMlsezUVk Subject: RE: [PATCH] cpuidle: Add "cpuidle.use_deepest" to bypass governor and allow HW to go deep Date: Fri, 24 Nov 2017 09:34:18 -0800 Message-ID: <000901d3654a$76411b80$62c35280$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdNe9adCoiaNTqugQBW0Zj17/fMfTgGSO5dQ Content-Language: en-ca X-CMAE-Envelope: MS4wfDXCeT4VaEGAsSieQRIYDiGsDCP4ubz2eAo6kxIq/syjIMZa7ShZ/7sqj69dfddNOqMN6ZWLy7YTnEh7+eOXPhLti9G9L/J1yS+92HODfLhT5rK6NIsf bW2GNXavc4PAsnWHktuOcuExQSacEilh8NjqlwY5d7VpK5PX4eQ3gb+wWoeHd5zN95n3eAM7Jtrhmw562iYqZFdWm0mQe5r3v7aHNJz8IMsyqQshAjG272MT D5HOCoVQVwmF/gpwOnqHc0Djd1osR8e5cnMfQv6Q9a8OwlCETxpYB/VGt8wwuHiLYEfX7f2rS4llYWDWcMdk9r6wpcg/DpRNn6pfWO4NwIknwd4P/J7spIBn 0/I/kySg Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017.11.16 08:11 Thomas Ilsche wrote: > On 2017-11-09 08:38, Len Brown wrote: >> From: Len Brown >> >> While there are several mechanisms (cmdline, sysfs, PM_QOS) to limit >> cpuidle to shallow idle states, there is no simple mechanism >> to give the hardware permission to enter the deeptest state permitted by PM_QOS. >> >> Here we create the "cpuidle.use_deepest" modparam to provide this capability. >> >> "cpuidle.use_deepest=Y" can be set at boot-time, and >> /sys/module/cpuidle/use_deepest can be modified (with Y/N) at run-time. > > This is a good option to have and can conveniently prevent idle power consumption > issues. But that wouldn't be a reasonable default, would it? > I still think there is an inherent need for a heuristic and a corresponding > mitigation to avoid staying in a sleep state too long. I think so, yes. The potential energy savings, depending on work flow, are significant. For the idle state 0 case, I have some supporting data that I will send on the other e-mail thread. ... Doug From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Doug Smythies" Subject: RE: [PATCH] cpuidle: Add "cpuidle.use_deepest" to bypass governor and allow HW to go deep Date: Fri, 24 Nov 2017 09:34:18 -0800 Message-ID: <000901d3654a$76411b80$62c35280$@net> References: <1d81edef71c936099f8bb9d16162f8e70fbe401c.1510212816.git.len.brown@intel.com> FMlqe98CNhCDuFMlsezUVk Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: FMlqe98CNhCDuFMlsezUVk Content-Language: en-ca Sender: linux-kernel-owner@vger.kernel.org To: 'Thomas Ilsche' , 'Len Brown' Cc: linux-pm@vger.kernel.org, jacob.jun.pan@linux.intel.com, linux-kernel@vger.kernel.org, 'Len Brown' List-Id: linux-pm@vger.kernel.org On 2017.11.16 08:11 Thomas Ilsche wrote: > On 2017-11-09 08:38, Len Brown wrote: >> From: Len Brown >> >> While there are several mechanisms (cmdline, sysfs, PM_QOS) to limit >> cpuidle to shallow idle states, there is no simple mechanism >> to give the hardware permission to enter the deeptest state permitted by PM_QOS. >> >> Here we create the "cpuidle.use_deepest" modparam to provide this capability. >> >> "cpuidle.use_deepest=Y" can be set at boot-time, and >> /sys/module/cpuidle/use_deepest can be modified (with Y/N) at run-time. > > This is a good option to have and can conveniently prevent idle power consumption > issues. But that wouldn't be a reasonable default, would it? > I still think there is an inherent need for a heuristic and a corresponding > mitigation to avoid staying in a sleep state too long. I think so, yes. The potential energy savings, depending on work flow, are significant. For the idle state 0 case, I have some supporting data that I will send on the other e-mail thread. ... Doug