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: <002101d18c2a$10fd0ef0$32f72cd0$@net>
Date:	Fri, 1 Apr 2016 08:20:17 -0700
From:	"Doug Smythies" <dsmythies@...us.net>
To:	"'Rafael J. Wysocki'" <rjw@...ysocki.net>,
	'Jörg Otte' <jrg.otte@...il.com>
Cc:	"'Rafael J. Wysocki'" <rafael@...nel.org>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>,
	"'Linux PM list'" <linux-pm@...r.kernel.org>,
	"'Srinivas Pandruvada'" <srinivas.pandruvada@...ux.intel.com>
Subject: RE: [intel-pstate driver regression] processor frequency very high even if in idle

On 2016.04.01 05:40 Rafael J. Wysocki wrote:
> On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote:
>> 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki <rjw@...ysocki.net>:
>>> On Thursday, March 31, 2016 05:25:18 PM Jörg Otte wrote:
>>>> 2016-03-31 13:42 GMT+02:00 Rafael J. Wysocki <rjw@...ysocki.net>:
>>>>> On Thursday, March 31, 2016 11:05:56 AM Jörg Otte wrote:

>> 
>> here they are.
>> 

> First of all, the sampling mechanics works as expected
> in the failing case, which is the most important thing
> I wanted to know.

Yes, but that might be part of the problem, as for some CPUs
there is never a long duration, and thus the long duration
check never kicks in driving the target pstate down.

> The core_busy column is clearly suspicious and it
> looks like CPUs 2 and 3 never really go idle.

This has been observed several times before [1].
Due to beat frequencies between desktop type frame rates
and such, the worst manifestation of the issue seems to be
for 300 Hz kernels, but Ubuntu uses uses 250 Hz.

Oh look, Jörg is using 300 Hz!!

$ grep CONFIG_HZ .config_jorg
# CONFIG_HZ_PERIODIC is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300

> I guess we'll need to find out
> why they don't go idle to get to the bottom of this, but it firmly falls into
> the weird stuff territory already.

I'm compiling a 300 Hz kernel now, also with "# CONFIG_NO_HZ is not set",
but I have never been able to re-create these type of findings before.

I have also tried several other things in an attempt re-create Jörg's
Case, so far without success.

References:
[1] https://bugzilla.kernel.org/show_bug.cgi?id=93521
In particular:
https://bugzilla.kernel.org/show_bug.cgi?id=93521#c35
https://bugzilla.kernel.org/show_bug.cgi?id=93521#c42
https://bugzilla.kernel.org/show_bug.cgi?id=93521#c77

... Doug


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ