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]

Message-ID: <20140528003540.GA2296@intel.com>
Date:	Wed, 28 May 2014 08:35:40 +0800
From:	Yuyang Du <yuyang.du@...el.com>
To:	Johan Hovold <jhovold@...il.com>
Cc:	Dirk Brandewie <dirk.brandewie@...il.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	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>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Doug Smythies <dsmythies@...us.net>,
	Stratos Karafotis <stratosk@...aphore.gr>
Subject: Re: Performance regression in v3.14

> I tried applying your (rejected) patch "intel_pstate: Remove C0
> tracking" posted here:
> 
> 	https://lkml.org/lkml/2014/5/8/574
> 
> to v3.14.4 and it fixes the problem as expected.
> 
> So we have a commit fcb6a15c2e7e ("intel_pstate: Take core C0 time into
> account for core busy calculation") that went into v3.14-rc2 (and was
> even marked for *stable*) that first broke Greg KH's system:
> 
> 	https://lkml.org/lkml/2014/2/19/626
> 
> That was apparently fixed by e66c17683746 ("intel_pstate: Change
> busy calculation to use fixed point math."), but still left v3.14
> basically unusable for lower-intensity workloads such as my
> bash-completion example and other reported regressions:
> 
> 	https://bugzilla.kernel.org/show_bug.cgi?id=75121
> 
> Sure there may be issues with v3.13 not hitting the lowest frequencies
> but at least the system was *usable*.
> 
> In my opinion there's really no other option than to restore the 3.13
> behaviour by effectively reverting fcb6a15c2e7e ("intel_pstate: Take
> core C0 time into account for core busy calculation") until you have
> figured out a way to take C0 into account without breaking things too
> badly.

Hi all,

My posts before and now are only relevant to why C0 tracking can't be
removed. Maybe I need to elaborate on it a little bit more.

In a nutshell, without C0 tracking, the intel_pstate is effectively performance
governor in terms of frequency control. Why?

Without C0 trakcing, the machinery of the freq control is as I formed:

last_freq_average / last_requested_freq ==> setpoint

which can be virtually formed into:

last_freq_average / last_requested_freq * last_C0_pct ==> setpoint * last_C0_pct

which said, the control machinery will increase the freuqency at ANY frequency at
ANY C0_pct (which is the CPU utilization), since setpoint is less then 100
percent. And a few iterations later, we will reach max (possible) frequency,
then we are effectively performance governor (highest frequency all the time).

So, sure, without C0 tracking, the performance issues should be fixed. But
let's simply set highest frequency, that should be better.

It is your decision whether we should remove C0 tracking as a no-other option fix
right now. I am ok either way.

Thanks,
Yuyang
--
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/