Re: 3.10-rcX: cpu governor ondemand doesn't scale well after s2ram

["Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>]

On 06/30/2013 07:52 PM, Rafael J. Wysocki wrote:
> On Saturday, June 29, 2013 07:50:11 PM Toralf Förster wrote:
>> The latest bisect attempt gave :
>>
>> commit a66b2e503fc79fff6632d02ef5a0ee47c1d2553d
>> Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>> Date:   Wed May 15 21:47:17 2013 +0200
>>
>>     cpufreq: Preserve sysfs files across suspend/resume
>>
>>     The file permissions of cpufreq per-cpu sysfs files are not preserved
>>     across suspend/resume because we internally go through the CPU
>>     Hotplug path which reinitializes the file permissions on CPU online.
>>
>>     But the user is not supposed to know that we are using CPU hotplug
>>     internally within suspend/resume (IOW, the kernel should not silently
>>     wreck the user-set file permissions across a suspend cycle).
>>     Therefore, we need to preserve the file permissions as they are
>>     across suspend/resume.
>>
>>     The simplest way to achieve that is to just not touch the sysfs files
>>     at all - ie., just ignore the CPU hotplug notifications in the
>>     suspend/resume path (_FROZEN) in the cpufreq hotplug callback.
>>
>>     Reported-by: Robert Jarzmik <robert.jarzmik@intel.com>
>>     Reported-by: Durgadoss R <durgadoss.r@intel.com>
>>     Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>>     Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>>     Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>>
>>
>> To get a more reliable bisect result I had to start BOINC before (4
>> childs each with nice -19 started)
> 
> Well, to be honest, I'm not really sure how the above commit can cause the
> problem you're seeing to happen ...
> 
> Srivatsa, Viresh, any ideas?
>

I tried to look up what problem is being reported, but apart from the hint
from the subject line, I couldn't find anything more. So, guessing that there
is something wrong with cpufreq after an s3 cycle, Toralf, can you please
try out the below patch and see if it improves anything? (Don't revert anything,
just apply the below diff on a problematic kernel and see if it solves your
issue).


---

 drivers/cpufreq/cpufreq_stats.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index fb65dec..591b6fb 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -349,6 +349,7 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb,
 
 	switch (action) {
 	case CPU_ONLINE:
+	case CPU_ONLINE_FROZEN:
 		cpufreq_update_policy(cpu);
 		break;
 	case CPU_DOWN_PREPARE: