Messages in this thread | | | Date | Tue, 6 Oct 2009 04:22:54 -0700 | Subject | Re: [BISECTED] "conservative" cpufreq governor broken | From | Steven Noonan <> |
| |
On Tue, Oct 6, 2009 at 3:43 AM, Eero Nurkkala <ext-eero.nurkkala@nokia.com> wrote: > On Tue, 2009-10-06 at 12:22 +0200, ext Steven Noonan wrote: >> >> I would suspect you have to have CONFIG_NO_HZ enabled to be able to >> reproduce the issue (considering the title of the bisected commit and >> my own config). Do you have it enabled? >> > > Yes, it's enabled. > >> > And another round: >> > >> > cpufreq stats: OP1:16,78%, OP2:0,24%, OP3:5,14%, OP4:77,83% (72) >> > >> > Just once more after doing nothing: >> > OP1:7,41%, OP2:0,11%, OP3:2,38%, OP4:90,10% (82) >> > >> > So I can't agree it's broken. The patch you bisected, actually filtered >> > out such phenomenon, in which an IRQ made the cpufreq framework >> > occasionally think we were idling, although we were not. So you got >> > "bonus" idle time that shouldn't been there in the first place. Now that >> > the "bonus" idle time is not there, your system load may indeed be so >> > high that the system never spends 80% or more time in idle? Could that >> > be the case? Of course, even though I can't agree it's broken, doesn't >> > mean it isn't somehow broken ;) It'd be nice to get info on other >> > systems as well... >> >> Interestingly, "ondemand" (the governor fixed by the bisected commit) >> works fine. "conservative" is the only broken one. >> > > If you took timestamps in /arch/x86/kernel/process_**.c: > (let's assume process_64.c) in cpu_idle() > around enter_idle(); and __exit_idle(), took the diff, > added the diffs up, and compared it to system uptime, you could see how > much time you spend in idle()? I think it's possible that > even if the cpu load is near 0%, the system may idle only for a bare > moment (that translates to a buggy pm_idle()), and time is spent > elsewhere (less than 80% in idle).
This makes logical sense, but how should I test this? Is there a way to do this with existing tracers?
By the way, a revert of the bisected commit changes the cpufreq stats favorably:
2333000 31 2167000 13 2000000 6 1833000 79 1667000 239 1500000 193 1333000 959 1000000 10260 2333000 11 2167000 13 2000000 13 1833000 26 1667000 33 1500000 333 1333000 59 1000000 11293
- Steven -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |