From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754719Ab3KTRX5 (ORCPT ); Wed, 20 Nov 2013 12:23:57 -0500 Received: from mga09.intel.com ([134.134.136.24]:10827 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754424Ab3KTRXy (ORCPT ); Wed, 20 Nov 2013 12:23:54 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.93,535,1378882800"; d="scan'208";a="438649453" Message-ID: <528CF028.2040002@linux.intel.com> Date: Wed, 20 Nov 2013 09:23:52 -0800 From: Arjan van de Ven User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Thomas Gleixner CC: Peter Zijlstra , lenb@kernel.org, rjw@rjwysocki.net, Eliezer Tamir , Chris Leech , David Miller , rui.zhang@intel.com, jacob.jun.pan@linux.intel.com, Mike Galbraith , Ingo Molnar , hpa@zytor.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, "Rafael J. Wysocki" Subject: Re: [PATCH 3/7] idle, thermal, acpi: Remove home grown idle implementations References: <20131120160450.072555619@infradead.org> <20131120162736.508462614@infradead.org> <528CE611.8040903@linux.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/20/2013 9:23 AM, Thomas Gleixner wrote: > On Wed, 20 Nov 2013, Arjan van de Ven wrote: > >> On 11/20/2013 8:04 AM, Peter Zijlstra wrote: >>> This does not fully preseve existing behaviour in that the generic >>> idle cycle function calls into the normal cpuidle governed idle >>> routines and should thus respect things like QoS parameters and the >>> like. >> >> >> NAK on the powerclamp side. >> >> powerclamp MUST NOT do that.... >> it is needed to go to the deepest state no matter what >> (this is for when your system is overheating. there is not a lot of choice >> here... alternative is an emergency reset that the hardware does for safety) > > So that whole machinery falls apart when the thing which is running on > that hot core is a while(1) loop with a higher or equal FIFO priority > than this thread. Even if you'd run at prio 99, then there is no > guarantee that the cpu hog does not run with prio 99 as well and due > to FIFO and being on the CPU it's not going to let you on. the idea was to at least give people who know what they're doing a chance to run