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:	Thu, 26 Nov 2015 19:28:38 -0800
From:	"Doug Smythies" <dsmythies@...us.net>
To:	"'Chen, Yu C'" <yu.c.chen@...el.com>
Cc:	"'Wysocki, Rafael J'" <rafael.j.wysocki@...el.com>,
	<tglx@...utronix.de>, <hpa@...or.com>, <bp@...en8.de>,
	"'Zhang, Rui'" <rui.zhang@...el.com>, <linux-pm@...r.kernel.org>,
	<x86@...nel.org>, <linux-kernel@...r.kernel.org>,
	"'Brown, Len'" <len.brown@...el.com>,
	"'Ingo Molnar'" <mingo@...nel.org>,
	"'Pavel Machek'" <pavel@....cz>,
	"'Pandruvada, Srinivas'" <srinivas.pandruvada@...el.com>,
	"'Doug Smythies'" <dsmythies@...us.net>
Subject: RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend

On 2015.11.21 08:45 Doug Smythies wrote:
>On 2015.11.12 01:42 Chen, Yu C wrote:
>> On 2015.11.06 11:34 Doug Smythies wrote: 

[cut]

>> rdmsr_safe  might be better,

> I'll look into it, thanks.

>> you can refer to acpi_throttling_rdmsr

> I don't understand.

>> and I'm OK with this code, are you planning to send a formal patch? 

> The delay here is because I have always thought that some actual load
> content needs to be brought back to the intel_pstate driver, which would
> (or at least should) eliminate the need for this patch.

> Anyway, and at least for the interim, I'll try to make and submit a formal version.

I made a mistake in my initial testing. I put a 100% load on CPU 7 and then
cycled through all the clock modulation values to show that my test version of
a possible patch compensated / normalized the Clock Modulation. Indeed, if the
system is already asking for the maximum pstate, it will stay there. However,
whenever the load drops, the target pstate will drop to minimum and it will
never kick back up again, regardless of load.

I am returning to my initial assertion copied below:

>>>>>>> The current version of the intel_pstate driver is incompatible
>>>>>>> with any use of Clock Modulation, always resulting in driving the
>>>>>>> target pstate to the minimum, regardless of load. The result is
>>>>>>> the apparent CPU frequency stuck at minimum * modulation percent.
>>>>>>
>>>>>>> The acpi-cpufreq driver works fine with Clock Modulation,
>>>>>>> resulting in desired frequency * modulation percent.

Chen,

Thanks though for the suggestion to try normalizing.

... Doug


--
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/

Powered by blists - more mailing lists