Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1278550

Re: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend

From Yu Chen <yu.c.chen@intel.com>
Newsgroups linux.kernel
Subject Re: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend
Date 2015-11-27 07:00 +0100
Message-ID <qzkeC-7c6-3@gated-at.bofh.it> (permalink)
References (6 earlier) <qq3Zo-2li-23@gated-at.bofh.it> <qrRho-6iP-23@gated-at.bofh.it> <qtWFZ-7bs-33@gated-at.bofh.it> <qxjwm-7TA-17@gated-at.bofh.it> <qzhTr-5KE-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi,
On 11/27/2015 11:28 AM, Doug Smythies wrote:
> 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.
>
  Do you mean even with your
  patch applied, the cpufreq policy would choose a smaller target?
  I looked up the SDM, it says in 14.7.3: on Hyper-Threading Technology
  enabled processors, the clock modulation might behave differently:
"if the programmed duty cycle is not identical for all logical
processors in the same core, the
processor core will modulate at the lowest programmed duty cycle "
I dont know if this is related to the problem.
> 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.
>
I'll try to reproduce your problem, and let's discuss this offline.
> ... Doug
>
thanks,
Yu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend "Doug Smythies" <dsmythies@telus.net> - 2015-11-21 17:50 +0100
  RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend "Doug Smythies" <dsmythies@telus.net> - 2015-11-27 04:30 +0100
    Re: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for  suspend Yu Chen <yu.c.chen@intel.com> - 2015-11-27 07:00 +0100

csiph-web