Messages in this thread | | | Date | Wed, 07 May 2014 07:10:49 -0700 | From | Dirk Brandewie <> | Subject | Re: Performance regression in v3.14 |
| |
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@gmail.com> 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 >
| |