From mboxrd@z Thu Jan 1 00:00:00 1970 From: Viresh Kumar Subject: Re: Ask for help on governor Date: Wed, 13 Dec 2017 11:47:59 +0530 Message-ID: <20171213061759.GT25177@vireshk-i7> References: <000801d37364$d48f6ed0$7dae4c70$@net> <000f01d373bf$deacca10$9c065e30$@net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pl0-f42.google.com ([209.85.160.42]:39844 "EHLO mail-pl0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750739AbdLMGSF (ORCPT ); Wed, 13 Dec 2017 01:18:05 -0500 Received: by mail-pl0-f42.google.com with SMTP id bi12so447743plb.6 for ; Tue, 12 Dec 2017 22:18:04 -0800 (PST) Content-Disposition: inline In-Reply-To: <000f01d373bf$deacca10$9c065e30$@net> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Doug Smythies Cc: "'Rafael J. Wysocki'" , 'Andy Tang' , "'Rafael J. Wysocki'" , 'Linux PM' On 12-12-17, 19:10, Doug Smythies wrote: > Thanks for the suggestion. It was so very close, the problem commit is the very > next one, aa7519af450d. > > Bisect result: > > aa7519af450d3c62a057aece24877c34562fa25a is the first bad commit > commit aa7519af450d3c62a057aece24877c34562fa25a > Author: Viresh Kumar > Date: Wed Jul 19 15:42:42 2017 +0530 > > cpufreq: Use transition_delay_us for legacy governors as well > > The policy->transition_delay_us field is used only by the schedutil > governor currently, and this field describes how fast the driver wants > the cpufreq governor to change CPUs frequency. It should rather be a > common thing across all governors, as it doesn't have any schedutil > dependency here. > > Create a new helper cpufreq_policy_transition_delay_us() to get the > transition delay across all governors. > > Signed-off-by: Viresh Kumar > Signed-off-by: Rafael J. Wysocki What has changed for intel-pstate after this patch ? sampling_rate for conservative and ondemand is 500 us now, which was 20000 us earlier. So we reevaluate load very frequently now, but in case load isn't over 80% then we wouldn't increase the frequency. @Doug/Andy: Can you please try following: - Checkout 4.14 or mainline (the broken kernels). - Set governor to conservative. - Monitor /sys/devices/system/cpu/cpufreq/policy*/stats/total_trans (to check if frequency is getting changed or not). - Run some dummy load, I did this: perf bench sched messaging --pipe --thread --group 8 This should result in frequency updates, so its not that we aren't changing frequency at all now with conservative. Then do this: echo 20000 > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate and this should take you back to the original behavior which was there pre-4.14. @Andy: What's your hardware and cpufreq driver ? intel-pstate? As I am not sure why things will change for any other driver than intel-pstate. I am not really sure what's the right way forward here now. -- viresh