On Wed, May 07, 2014 at 11:10:34AM +0530, Viresh Kumar wrote: > Cc'ing Dirk who is taking care of intel-pstate driver. > > 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). <snip> > 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? Using acpi-cpufreq and the ondemand governor (with all 8 cores online) on 3.14.3 improves the situation somewhat: $ time cat dmesg.repeat | while read x; do true; done real 0m1.989s user 0m1.257s sys 0m0.747s when the system is idle, and $ time cat dmesg.repeat | while read x; do true; done real 0m1.191s user 0m0.753s sys 0m0.449s when run a second time in immediate succession. When running the same tests on 3.13.11, the figures are roughly the same $ time cat dmesg.repeat | while read x; do true; done real 0m2.075s user 0m1.276s sys 0m0.816s $ time cat dmesg.repeat | while read x; do true; done real 0m1.291s user 0m0.800s sys 0m0.504s So I guess that idle-active difference is normal for acpi-cpufreq and that the problem only arises in or with the intel_pstate driver. Thanks, Johan -- 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
