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

[Yu Chen]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/