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

Groups > linux.kernel > #1260200

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

Show all headers | View raw

Hi, Doug,
Sorry for my late response, and thanks for your information:

> -----Original Message-----
> From: Doug Smythies [mailto:dsmythies@telus.net]
> Sent: Sunday, October 11, 2015 11:47 PM
> To: Chen, Yu C
> Cc: Wysocki, Rafael J; tglx@linutronix.de; hpa@zytor.com; bp@alien8.de;
> Zhang, Rui; linux-pm@vger.kernel.org; x86@kernel.org; linux-
> kernel@vger.kernel.org; Brown, Len; 'Ingo Molnar'; 'Pavel Machek'; 'Kristen
> Carlson Accardi'; Doug Smythies
> Subject: RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for
> suspend
> 
> Hi Yu, thanks for your reply.
> 
> On 2015.10.10 19:27 Chen, Yu C wrote:
> > On 2105.10.10 02:56 Doug Smythies wrote:
> >
> >>> 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.
> >>
> 
> > [Yu] Why intel_pstate driver is incompatible with Clock Modulation?
> 
> It is simply how the current control algorithm responds to the scenario.
> 
> The problem is in intel_pstate_get_scaled_busy, here:
> 
>         /*
>          * core_busy is the ratio of actual performance to max
>          * max_pstate is the max non turbo pstate available
>          * current_pstate was the pstate that was requested during
>          *      the last sample period.
>          *
>          * We normalize core_busy, which was our actual percent
>          * performance to what we requested during the last sample
>          * period. The result will be a percentage of busy at a
>          * specified pstate.
>          */
>         core_busy = cpu->sample.core_pct_busy;
>         max_pstate = int_tofp(cpu->pstate.max_pstate);
>         current_pstate = int_tofp(cpu->pstate.current_pstate);
>         core_busy = mul_fp(core_busy, div_fp(max_pstate, current_pstate));
> 
> With Clock Modulation enabled, the actual performance percent will always
> be less than what was asked for, basically meaning current_pstate is much
> less than what was asked for. Thus the algorithm will drive down the target
> pstate regardless of load.
> 
[Yu] Do you mean, there is some problem with the normalization,and we should use 
the actual pstate rather than the theoretical current_pstate, for example, 
the pseudocode might looked like:

-  current_pstate = int_tofp(cpu->pstate.current_pstate);
+ current_pstate = int_tofp(cpu->pstate.current_pstat)*0.85;

Best Regards,
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 — Next in thread | Find similar | Unroll thread

Thread

RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for  suspend "Chen, Yu C" <yu.c.chen@intel.com> - 2015-11-01 17:50 +0100
  RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend "Doug Smythies" <dsmythies@telus.net> - 2015-11-06 16:40 +0100
    RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for  suspend "Chen, Yu C" <yu.c.chen@intel.com> - 2015-11-12 10:50 +0100

csiph-web