https://bugzilla.kernel.org/show_bug.cgi?id=55411 --- Comment #38 from Viresh Kumar <viresh.kumar@xxxxxxxxxx> 2013-03-25 11:23:40 --- On 25 March 2013 16:45, Duncan <1i5t5.duncan@xxxxxxx> wrote: > FWIW, with this patch, pre-s2ram and post-resume are indeed consistent, > but it's not back to where it was. > > With this patch, each core is a cpufreq law unto itself. Maybe that's > what you meant with the note, maybe not (I know the mapping of sysfs > files to cpufreq-info output was stated up-thread, but I lost track, > and how affected vs related maps to hardware vs software coordinated > and what it all actually means other than what I'm seeing isn't ideal, > is apparently a bit more than I'm able to keep in my head ATM), but it's > what I get. The relevant bits of cpufreq-info output: > > analyzing CPU 0: > CPUs which run at the same hardware frequency: 0 > CPUs which need to have their frequency coordinated by software: 0 > analyzing CPU 1: > CPUs which run at the same hardware frequency: 1 > CPUs which need to have their frequency coordinated by software: 1 > analyzing CPU 2: > CPUs which run at the same hardware frequency: 2 > CPUs which need to have their frequency coordinated by software: 2 > analyzing CPU 3: > CPUs which run at the same hardware frequency: 3 > CPUs which need to have their frequency coordinated by software: 3 > analyzing CPU 4: > CPUs which run at the same hardware frequency: 4 > CPUs which need to have their frequency coordinated by software: 4 > analyzing CPU 5: > CPUs which run at the same hardware frequency: 5 > CPUs which need to have their frequency coordinated by software: 5 > > But at least it's consistent: The same results both before and after a > suspend/resume cycle. > > And given that 3.8 wasn't ideal either, maybe that's good enough for > this cycle, and a real fix will have to wait until the next commit > window and stable-tree. That'd give us more leeway to fix it right, as > well as a full cycle for testing anything else the "correct" fix might > dredge up. This is exactly what i expected and i wrote in Note. Because cpufreq core does a lot of work based on related_cpus now, its better we don't set it blindly for x86. Following code was the only user of relatead_cpus in 3.8 code: /* Set governor before ->init, so that driver could check it */ #ifdef CONFIG_HOTPLUG_CPU for_each_online_cpu(sibling) { struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling); if (cp && cp->governor && (cpumask_test_cpu(cpu, cp->related_cpus))) { policy->governor = cp->governor; found = 1; break; } } #endif There is no other user of relatead_cpus earlier in cpufreq core and that's why i wonder why it was added earlier. But a grep of relatead_cpus for 3.8 showed some interesting users in: tools/power/cpupower/ I will try to check what they are doing with it, but for the kernel it was almost unused. And not it is very much used :) But for 3.9 i believe this patch should be good enough. Thanks for testing it. -- viresh -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
