From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH] cpufreq: ondemand: Change the calculation of target frequency Date: Mon, 03 Jun 2013 12:57:47 +0200 Message-ID: <2413427.Abjbfkms0Z@vostro.rjw.lan> References: <51A7BFA6.3070800@semaphore.gr> Mime-Version: 1.0 Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Viresh Kumar Cc: Stratos Karafotis , linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org On Monday, June 03, 2013 12:25:02 PM Viresh Kumar wrote: > Sent half written mail.. sorry.. will continue from where I left. > > On 3 June 2013 12:21, Viresh Kumar wrote: > > > So, obviously the calculations aren't the same.. > > Now, this is how I understood these two different variables: > - cpuinfo.max_freq: maximum frequency (in kHz) which is > supported by this CPU > - policy->max: Maximum frequency forced by user or governor > > When somebody sets policy->max, he expects cpufreq core to > use the range between min and max as the slope cpufreq core > has and adjust its frequencies accordingly.. > > Don't know if I am right or wrong :( The reality is that the set of frequencies to use is constant and changing policy->max doesn't change that set. There are just fewer frequencies the governor can choose from if policy->max is below cpuinfo.max_freq. The question is if we want policy->max to re-scale them effectively (i.e. to change weights so that the maximum load maps to the highest frequency available at the moment) or if we want policy->max to work as a cap (i.e. to map all loads above certain value to the maximum frequency available at the moment, so that the criteria for selecting the lower frequencies don't change). In my opinion the second option is better, because it means "OK, we can't use some high frequencies, but let's not hurt performance for the loads that wouldn't require them anyway". Otherwise, we'll effectively throttle all loads and that not only causes performance to drop, but also causes more energy to be used overall. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.