From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dominik Brodowski Subject: Re: CPUFreq dynamic speed governor, take 2. Date: Tue, 4 Nov 2003 14:42:46 +0100 Sender: cpufreq-bounces@www.linux.org.uk Message-ID: <20031104134246.GA4536@brodo.de> References: <88056F38E9E48644A0F562A38C64FB600779D0@scsmsx403.sc.intel.com> <20031103222510.GB3895@brodo.de> <20031104102426.GH21970@poupinou.org> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20031104102426.GH21970@poupinou.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cpufreq-bounces@www.linux.org.uk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Ducrot Bruno Cc: Jon Anderson , cpufreq@www.linux.org.uk On Tue, Nov 04, 2003 at 11:24:26AM +0100, Ducrot Bruno wrote: > > What about +/- 5 % of cpuinfo->max_freq? or +/- 10 % of (policy->max_freq - > > policy->min_freq). I think the governor does not need to know of supported > > frequencies: the governor says "I need at least n % of processing > > power" == "I need m bogomips of processing power" == (o, CPUFREQ_RELATION_L) > > or it says "I need no more than..." == (o, CPUFREQ_RELATION_H) > > > > Most of the demand based stuff I see seems to need more "I need to > go up/down one step." I am not sure that it is a bad design. What if there are thousand steps, or even more [like for the geode driver]? Then this approach is badly broken. > Or else, you loose probably the speedstep stuff for example (something > like go up 10%, not enough, go up 10%, etc.). You might miss some intermediate steps if you select a too large interval here. However, there are other algorithms which calculate a "needed CPU percentage" directly, and they won't miss any speedstep state. Dominik