linux-kernel - Re: Performance regression in v3.14

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 May 2014 11:00:51 +0200
From:	Johan Hovold <jhovold@...il.com>
To:	Dirk Brandewie <dirk.brandewie@...il.com>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	Johan Hovold <jhovold@...il.com>, dirk.j.brandewie@...el.com,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Performance regression in v3.14

On Wed, May 07, 2014 at 07:10:49AM -0700, Dirk Brandewie wrote:
> 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

Any updates on this, Dirk? 3.14 is still basically unusable with the
intel_pstate driver.

Any fixes or workarounds posted elsewhere that I can apply in the
meantime?

Thanks,
Johan

> > On 6 May 2014 22:05, Johan Hovold <jhovold@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/