On 05/06/2014 10:40 PM, Viresh Kumar wrote:
Cc'ing Dirk who is taking care of intel-pstate driver.
Thanks Viresh I had seen this thread. I am looking into it --Dirk
On 6 May 2014 22:05, Johan Hovold <jhovold@xxxxxxxxx> wrote:After updating my main system from v3.13 to v3.14.2, I found that the git bash-completion was extremely sluggish. Completing a file name would take roughly six rather than one second on this Haswell machine (i7-4770). (Other things, such as git rebase, also felt slower, but the completion issue was much more obvious and easy to measure). I managed to reproduce the problem using the following minimal construct cat dmesg.repeat | while read x; do true; done where dmesg.repeat is simply dmesg concatenated together to an equivalent number of lines as produced by git ls-files in the kernel-source tree root (45k), and where the actual processing of each line has been removed. Most of the time I get: $ time cat dmesg.repeat | while read x; do true; done real 0m6.091s user 0m3.674s sys 0m2.447s but sometimes it only takes one second. $ time cat dmesg.repeat | while read x; do true; done real 0m1.100s user 0m0.544s sys 0m0.570s I don't seem to be able to reproduce the problem on 3.13 where the pipe always takes about one second to finish. Taking all but one core offline seems to make the problem go away, and so does using the performance rather than powersave governor of the intel_pstate cpufreq driver (on at least one of two online cores). Moving the mouse cursor makes to loop finish faster, and so does switching to a another terminal to print cpufreq/cpuinfo_cur_freq which was around cpuinfo_min_freq several times (when tracing, see below). I could not reproduce the problem when using perf record, but I can get function-profile traces using ftrace (in which case the loop takes about 60 seconds instead of six seconds to finish). Comparing the traces I see a lot of functions taking ten times longer to finish, but I guess that's expected if this is indeed a cpufreq issue. Since this is my main machine (and only multi-core machine at the moment) I'm not able to bisect this myself. And for the same reason I have not verified that the problem persists in v3.15-rc. I don't see any cpufreq patches in the v3.14.3 stable queue nor anything obviously related and marked for stable in v3.15-rc. Any ideas about what might be going on?I tried to take a look at the diff for cpufreq between 3.13 and 3.14.2 and couldn't pin point on any change which might cause it. Don't have a clue of what's going on. I don't know how to help you on this. Normally I test my stuff on a ARM board and I don't remember facing any such behavior there. There might be something wrong with intel-pstate as well.. Also, can you try to use acpi-cpufreq instead? And see how that is behaving? -- viresh
-- 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
