| Message ID | 1448022757-7856-2-git-send-email-prarit@redhat.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On 20-11-15, 07:32, Prarit Bhargava wrote: > I have a Intel (6,63) processor with a "marketing" frequency (from > /proc/cpuinfo) of 2100MHz, and a max turbo frequency of 2600MHz. I > can execute > > cpupower frequency-set -g powersave --min 1200MHz --max 2100MHz > > and the max_freq_pct is set to 80. When adding load to the system I noticed > that the cpu frequency only reached 2000MHZ and not 2100MHz as expected. > > This is because limits->max_policy_pct is calculated as 2100 * 100 /2600 = 80.7 > and is rounded down to 80 when it should be rounded up to 81. This patch > adds a DIV_ROUND_UP() which will return the correct value. > > Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> > Cc: Len Brown <len.brown@intel.com> > Cc: Alexandra Yates <alexandra.yates@intel.com> > Cc: Kristen Carlson Accardi <kristen@linux.intel.com> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: linux-pm@vger.kernel.org > Signed-off-by: Prarit Bhargava <prarit@redhat.com> > --- > drivers/cpufreq/intel_pstate.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index 001a532..6b63374 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -1110,6 +1110,8 @@ static int intel_pstate_set_policy(struct cpufreq_policy *policy) > limits->min_policy_pct = clamp_t(int, limits->min_policy_pct, 0 , 100); > limits->max_policy_pct = (policy->max * 100) / policy->cpuinfo.max_freq; Forgot to remove this line ? > limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100); And put this after the later one ? > + limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100, > + policy->cpuinfo.max_freq); > > /* Normalize user input to [min_policy_pct, max_policy_pct] */ > limits->min_perf_pct = max(limits->min_policy_pct, Sure you tested it ? :)
On 11/20/2015 08:18 AM, Viresh Kumar wrote: > On 20-11-15, 07:32, Prarit Bhargava wrote: >> I have a Intel (6,63) processor with a "marketing" frequency (from >> /proc/cpuinfo) of 2100MHz, and a max turbo frequency of 2600MHz. I >> can execute >> >> cpupower frequency-set -g powersave --min 1200MHz --max 2100MHz >> >> and the max_freq_pct is set to 80. When adding load to the system I noticed >> that the cpu frequency only reached 2000MHZ and not 2100MHz as expected. >> >> This is because limits->max_policy_pct is calculated as 2100 * 100 /2600 = 80.7 >> and is rounded down to 80 when it should be rounded up to 81. This patch >> adds a DIV_ROUND_UP() which will return the correct value. >> >> Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> >> Cc: Len Brown <len.brown@intel.com> >> Cc: Alexandra Yates <alexandra.yates@intel.com> >> Cc: Kristen Carlson Accardi <kristen@linux.intel.com> >> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> >> Cc: Viresh Kumar <viresh.kumar@linaro.org> >> Cc: linux-pm@vger.kernel.org >> Signed-off-by: Prarit Bhargava <prarit@redhat.com> >> --- >> drivers/cpufreq/intel_pstate.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c >> index 001a532..6b63374 100644 >> --- a/drivers/cpufreq/intel_pstate.c >> +++ b/drivers/cpufreq/intel_pstate.c >> @@ -1110,6 +1110,8 @@ static int intel_pstate_set_policy(struct cpufreq_policy *policy) >> limits->min_policy_pct = clamp_t(int, limits->min_policy_pct, 0 , 100); >> limits->max_policy_pct = (policy->max * 100) / policy->cpuinfo.max_freq; > > Forgot to remove this line ? > >> limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100); > > And put this after the later one ? > >> + limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100, >> + policy->cpuinfo.max_freq); >> >> /* Normalize user input to [min_policy_pct, max_policy_pct] */ >> limits->min_perf_pct = max(limits->min_policy_pct, > > Sure you tested it ? :) Oops -- and yeah, tested. It works because I rewrite the value of max_policy_pct :). I'll repost shortly. P. > -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 20-11-15, 10:10, Prarit Bhargava wrote: > >> limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100); > > > > And put this after the later one ? > > > >> + limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100, > >> + policy->cpuinfo.max_freq); > >> > >> /* Normalize user input to [min_policy_pct, max_policy_pct] */ > >> limits->min_perf_pct = max(limits->min_policy_pct, > > > > Sure you tested it ? :) > > Oops -- and yeah, tested. It works because I rewrite the value of > max_policy_pct :). I'll repost shortly. But we aren't doing below anymore, doesn't this change the calculations at all? limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100);
On 11/20/2015 10:19 AM, Viresh Kumar wrote: > On 20-11-15, 10:10, Prarit Bhargava wrote: >>>> limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100); >>> >>> And put this after the later one ? >>> >>>> + limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100, >>>> + policy->cpuinfo.max_freq); >>>> >>>> /* Normalize user input to [min_policy_pct, max_policy_pct] */ >>>> limits->min_perf_pct = max(limits->min_policy_pct, >>> >>> Sure you tested it ? :) >> >> Oops -- and yeah, tested. It works because I rewrite the value of >> max_policy_pct :). I'll repost shortly. > > But we aren't doing below anymore, doesn't this change the > calculations at all? > > limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100); The clamp only confines the max_policy between 0 and 100. AFAIK it doesn't make any change tothe value of limits->max_policy_pct unless it was outside of that range. P. > -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
T24gRnJpLCAyMDE1LTExLTIwIGF0IDEwOjQzIC0wNTAwLCBQcmFyaXQgQmhhcmdhdmEgd3JvdGU6 DQo+IA0KPiBPbiAxMS8yMC8yMDE1IDEwOjE5IEFNLCBWaXJlc2ggS3VtYXIgd3JvdGU6DQo+ID4g T24gMjAtMTEtMTUsIDEwOjEwLCBQcmFyaXQgQmhhcmdhdmEgd3JvdGU6DQo+ID4+Pj4gIAlsaW1p dHMtPm1heF9wb2xpY3lfcGN0ID0gY2xhbXBfdChpbnQsIGxpbWl0cy0+bWF4X3BvbGljeV9wY3Qs IDAgLCAxMDApOw0KPiA+Pj4NCj4gPj4+IEFuZCBwdXQgdGhpcyBhZnRlciB0aGUgbGF0ZXIgb25l ID8NCj4gPj4+DQo+ID4+Pj4gKwlsaW1pdHMtPm1heF9wb2xpY3lfcGN0ID0gRElWX1JPVU5EX1VQ KHBvbGljeS0+bWF4ICogMTAwLA0KPiA+Pj4+ICsJCQkJCSAgICAgIHBvbGljeS0+Y3B1aW5mby5t YXhfZnJlcSk7DQo+ID4+Pj4gIA0KPiA+Pj4+ICAJLyogTm9ybWFsaXplIHVzZXIgaW5wdXQgdG8g W21pbl9wb2xpY3lfcGN0LCBtYXhfcG9saWN5X3BjdF0gKi8NCj4gPj4+PiAgCWxpbWl0cy0+bWlu X3BlcmZfcGN0ID0gbWF4KGxpbWl0cy0+bWluX3BvbGljeV9wY3QsDQo+ID4+Pg0KPiA+Pj4gU3Vy ZSB5b3UgdGVzdGVkIGl0ICA/IDopDQo+ID4+DQo+ID4+IE9vcHMgLS0gYW5kIHllYWgsIHRlc3Rl ZC4gIEl0IHdvcmtzIGJlY2F1c2UgSSByZXdyaXRlIHRoZSB2YWx1ZSBvZg0KPiA+PiBtYXhfcG9s aWN5X3BjdCA6KS4gIEknbGwgcmVwb3N0IHNob3J0bHkuDQo+ID4gDQo+ID4gQnV0IHdlIGFyZW4n dCBkb2luZyBiZWxvdyBhbnltb3JlLCBkb2Vzbid0IHRoaXMgY2hhbmdlIHRoZQ0KPiA+IGNhbGN1 bGF0aW9ucyBhdCBhbGw/DQo+ID4gDQo+ID4gICAJbGltaXRzLT5tYXhfcG9saWN5X3BjdCA9IGNs YW1wX3QoaW50LCBsaW1pdHMtPm1heF9wb2xpY3lfcGN0LCAwICwgMTAwKTsNCj4gDQo+IFRoZSBj bGFtcCBvbmx5IGNvbmZpbmVzIHRoZSBtYXhfcG9saWN5IGJldHdlZW4gMCBhbmQgMTAwLiAgQUZB SUsgaXQgZG9lc24ndCBtYWtlDQo+IGFueSBjaGFuZ2UgdG90aGUgdmFsdWUgb2YgbGltaXRzLT5t YXhfcG9saWN5X3BjdCB1bmxlc3MgaXQgd2FzIG91dHNpZGUgb2YgdGhhdA0KPiByYW5nZS4NCj4g DQo+IFAuDQo+ID4gDQoNCldpdGggdGhlIGNoYW5nZXMgYmVsb3cgKGFzIHN1Z2dlc3RlZCBhYm92 ZSksIEkgZGlkIHRlc3RzLiBFeGNlcHQgdHdvDQpjYXNlcywgaXQgZGlkIGNvcnJlY3QuIFRob3Nl IHR3byBhcmUgaW4gdHVyYm8gcmFuZ2UsIHNvIEkgYW0gT0sgd2l0aA0KdGhhdC4gDQoNCg0KZGlm ZiAtLWdpdCBhL2RyaXZlcnMvY3B1ZnJlcS9pbnRlbF9wc3RhdGUuYw0KYi9kcml2ZXJzL2NwdWZy ZXEvaW50ZWxfcHN0YXRlLmMNCmluZGV4IGI3OGFiZTkuLmMzYmNjYTQgMTAwNjQ0DQotLS0gYS9k cml2ZXJzL2NwdWZyZXEvaW50ZWxfcHN0YXRlLmMNCisrKyBiL2RyaXZlcnMvY3B1ZnJlcS9pbnRl bF9wc3RhdGUuYw0KQEAgLTExMTEsOSArMTExMSw5IEBAIHN0YXRpYyBpbnQgaW50ZWxfcHN0YXRl X3NldF9wb2xpY3koc3RydWN0DQpjcHVmcmVxX3BvbGljeSAqcG9saWN5KQ0KIAlsaW1pdHMgPSAm cG93ZXJzYXZlX2xpbWl0czsNCiAJbGltaXRzLT5taW5fcG9saWN5X3BjdCA9IChwb2xpY3ktPm1p biAqIDEwMCkgLw0KcG9saWN5LT5jcHVpbmZvLm1heF9mcmVxOw0KIAlsaW1pdHMtPm1pbl9wb2xp Y3lfcGN0ID0gY2xhbXBfdChpbnQsIGxpbWl0cy0+bWluX3BvbGljeV9wY3QsIDAgLA0KMTAwKTsN Ci0JbGltaXRzLT5tYXhfcG9saWN5X3BjdCA9IChwb2xpY3ktPm1heCAqIDEwMCkgLw0KcG9saWN5 LT5jcHVpbmZvLm1heF9mcmVxOw0KKwlsaW1pdHMtPm1heF9wb2xpY3lfcGN0ID0gRElWX1JPVU5E X1VQKHBvbGljeS0+bWF4ICogMTAwLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHBvbGljeS0+Y3B1aW5mby5tYXhfZnJlcSk7DQogCWxpbWl0cy0+bWF4X3Bv bGljeV9wY3QgPSBjbGFtcF90KGludCwgbGltaXRzLT5tYXhfcG9saWN5X3BjdCwgMCAsDQoxMDAp Ow0KLQ0KIAkvKiBOb3JtYWxpemUgdXNlciBpbnB1dCB0byBbbWluX3BvbGljeV9wY3QsIG1heF9w b2xpY3lfcGN0XSAqLw0KIAlsaW1pdHMtPm1pbl9wZXJmX3BjdCA9IG1heChsaW1pdHMtPm1pbl9w b2xpY3lfcGN0LA0KIAkJCQkgICBsaW1pdHMtPm1pbl9zeXNmc19wY3QpOw0KQEAgLTExMzEsNyAr MTEzMSw3IEBAIHN0YXRpYyBpbnQgaW50ZWxfcHN0YXRlX3NldF9wb2xpY3koc3RydWN0DQpjcHVm cmVxX3BvbGljeSAqcG9saWN5KQ0KIAkJCQkgIGludF90b2ZwKDEwMCkpOw0KIAlsaW1pdHMtPm1h eF9wZXJmID0gZGl2X2ZwKGludF90b2ZwKGxpbWl0cy0+bWF4X3BlcmZfcGN0KSwNCiAJCQkJICBp bnRfdG9mcCgxMDApKTsNCi0NCisJbGltaXRzLT5tYXhfcGVyZiA9IHJvdW5kX3VwKGxpbWl0cy0+ bWF4X3BlcmYsIDgpOw0KIAlpZiAoaHdwX2FjdGl2ZSkNCiAJCWludGVsX3BzdGF0ZV9od3Bfc2V0 KCk7DQoNCg0KMzMwMCA6IE9LDQozMjAwIDogMSBsZXNzDQozMTAwIDogMSBsZXNzDQozMDAwIDog MSBsZXNzDQoyOTAwIDogT0sNCjI4MDAgOiBPSw0KMjcwMCA6IE9LDQoyNjAwIDogT0sNCjI1MDAg OiBPSw0KMjQwMCA6IE9LDQoyMzAwIDogT0sNCjIyMDAgOiBPSw0KMjEwMCA6IE9LDQoyMDAwIDog T0sNCjE5MDAgOiBPSw0KMTgwMCA6IE9LDQoxNzAwIDogT0sNCjE2MDAgOiBPSw0KMTUwMCA6IE9L DQoxNDAwIDogT0sNCjEzMDAgOiBPSw0KMTIwMCA6IE9LDQoxMTAwIDogT0sNCjEwMDAgOiBPSw0K OTAwICA6IE9LDQo4MDAgOiBPSw0KDQpUaGFua3MsDQpTcmluaXZhcw0K -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/20/2015 03:02 PM, Pandruvada, Srinivas wrote: > On Fri, 2015-11-20 at 10:43 -0500, Prarit Bhargava wrote: >> >> On 11/20/2015 10:19 AM, Viresh Kumar wrote: >>> On 20-11-15, 10:10, Prarit Bhargava wrote: >>>>>> limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100); >>>>> >>>>> And put this after the later one ? >>>>> >>>>>> + limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100, >>>>>> + policy->cpuinfo.max_freq); >>>>>> >>>>>> /* Normalize user input to [min_policy_pct, max_policy_pct] */ >>>>>> limits->min_perf_pct = max(limits->min_policy_pct, >>>>> >>>>> Sure you tested it ? :) >>>> >>>> Oops -- and yeah, tested. It works because I rewrite the value of >>>> max_policy_pct :). I'll repost shortly. >>> >>> But we aren't doing below anymore, doesn't this change the >>> calculations at all? >>> >>> limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100); >> >> The clamp only confines the max_policy between 0 and 100. AFAIK it doesn't make >> any change tothe value of limits->max_policy_pct unless it was outside of that >> range. >> >> P. >>> > > With the changes below (as suggested above), I did tests. Except two > cases, it did correct. Those two are in turbo range, so I am OK with > that. > > > diff --git a/drivers/cpufreq/intel_pstate.c > b/drivers/cpufreq/intel_pstate.c > index b78abe9..c3bcca4 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -1111,9 +1111,9 @@ static int intel_pstate_set_policy(struct > cpufreq_policy *policy) > limits = &powersave_limits; > limits->min_policy_pct = (policy->min * 100) / > policy->cpuinfo.max_freq; > limits->min_policy_pct = clamp_t(int, limits->min_policy_pct, 0 , > 100); > - limits->max_policy_pct = (policy->max * 100) / > policy->cpuinfo.max_freq; > + limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100, > + policy->cpuinfo.max_freq); > limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , > 100); > - > /* Normalize user input to [min_policy_pct, max_policy_pct] */ > limits->min_perf_pct = max(limits->min_policy_pct, > limits->min_sysfs_pct); > @@ -1131,7 +1131,7 @@ static int intel_pstate_set_policy(struct > cpufreq_policy *policy) > int_tofp(100)); > limits->max_perf = div_fp(int_tofp(limits->max_perf_pct), > int_tofp(100)); > - > + limits->max_perf = round_up(limits->max_perf, 8); > if (hwp_active) > intel_pstate_hwp_set(); > > > 3300 : OK > 3200 : 1 less > 3100 : 1 less > 3000 : 1 less The -1 difference here is not unexpected given the other probable rounding errors in the frequency code. I have a feeling that no one really has done an in depth review to find the errors. I'm not going to because I'm pretty sure I/we can convince users that 3200 == 3199.98 ;). FWIW, I've also wondered if the difference between the marketing frequency and the TSC frequency (which in theory equals the marketing frequency) can cause this sort of error. OOC did you try loading the system down (with a kernel build) and switching between frequencies? That's a good way to see the effect of the turbo states. I would expect that the turbo state hits a maximum of about 75% of the max turbo state value (based on experiment) so the differences should be larger at the high end. P. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
T24gRnJpLCAyMDE1LTExLTIwIGF0IDE4OjQ3IC0wNTAwLCBQcmFyaXQgQmhhcmdhdmEgd3JvdGU6 DQo+IA0KW2N1dF0NCj4gVGhlIC0xIGRpZmZlcmVuY2UgaGVyZSBpcyBub3QgdW5leHBlY3RlZCBn aXZlbiB0aGUgb3RoZXIgcHJvYmFibGUgcm91bmRpbmcNCj4gZXJyb3JzIGluIHRoZSBmcmVxdWVu Y3kgY29kZS4NClllcy4gSW50ZWwgUCBzdGF0ZSBjcHVmcmVxIGludGVyZmFjZSBpcyBub3Qgb3B0 aW1hbC4gV2UgZXZlbiBkZWJhdGUNCndoZXRoZXIgd2Ugc2hvdWxkIGhhdmUgdGhpcyBpbnRlcmZh Y2UgYXQgYWxsLg0KDQo+ICAgSSBoYXZlIGEgZmVlbGluZyB0aGF0IG5vIG9uZSByZWFsbHkgaGFz IGRvbmUgYW4NCj4gaW4gZGVwdGggcmV2aWV3IHRvIGZpbmQgdGhlIGVycm9ycy4gIEknbSBub3Qg Z29pbmcgdG8gYmVjYXVzZSBJJ20gcHJldHR5IHN1cmUNCj4gSS93ZSBjYW4gY29udmluY2UgdXNl cnMgdGhhdCAzMjAwID09IDMxOTkuOTggOykuICBGV0lXLCBJJ3ZlIGFsc28gd29uZGVyZWQgaWYN Cj4gdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbWFya2V0aW5nIGZyZXF1ZW5jeSBhbmQgdGhl IFRTQyBmcmVxdWVuY3kgKHdoaWNoIGluDQo+IHRoZW9yeSBlcXVhbHMgdGhlIG1hcmtldGluZyBm cmVxdWVuY3kpIGNhbiBjYXVzZSB0aGlzIHNvcnQgb2YgZXJyb3IuDQpXZSBkb24ndCBldmVuIHJl cXVlc3QgY29ycmVjdCBwc3RhdGUgaGVyZSwgc28gd2Ugd2lsbCBub3QgZ2V0IHRoYXQuIEJ1dA0K aW4gdGhpcyBjYXNlIGluIHR1cmJvIHJlZ2lvbiBpcyBub3QgY29udHJvbGxhYmxlIChhZnRlciBT YW5keWJyaWRnZSApDQphYm92ZSBzb21ldGhpbmcgY2FsbGVkIHR1cmJvIGFjdGl2YXRpb24gcmF0 aW8uIFNvIG5vdCBhIGJpZyBkZWFsLg0KQXMgbG9uZyBhcyB3ZSBjYW4gc2V0IGF0IGxvd2VyIGVu ZCB3ZSBhcmUgZmluZS4NCj4gDQoNClRoYW5rcywNClNyaW5pdmFzDQoNCj4gT09DIGRpZCB5b3Ug dHJ5IGxvYWRpbmcgdGhlIHN5c3RlbSBkb3duICh3aXRoIGEga2VybmVsIGJ1aWxkKSBhbmQgc3dp dGNoaW5nDQo+IGJldHdlZW4gZnJlcXVlbmNpZXM/ICBUaGF0J3MgYSBnb29kIHdheSB0byBzZWUg dGhlIGVmZmVjdCBvZiB0aGUgdHVyYm8gc3RhdGVzLg0KPiBJIHdvdWxkIGV4cGVjdCB0aGF0IHRo ZSB0dXJibyBzdGF0ZSBoaXRzIGEgbWF4aW11bSBvZiBhYm91dCA3NSUgb2YgdGhlIG1heCB0dXJi bw0KPiBzdGF0ZSB2YWx1ZSAoYmFzZWQgb24gZXhwZXJpbWVudCkgc28gdGhlIGRpZmZlcmVuY2Vz IHNob3VsZCBiZSBsYXJnZXIgYXQgdGhlDQo+IGhpZ2ggZW5kLg0KPiANCj4gUC4NCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 001a532..6b63374 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -1110,6 +1110,8 @@ static int intel_pstate_set_policy(struct cpufreq_policy *policy) limits->min_policy_pct = clamp_t(int, limits->min_policy_pct, 0 , 100); limits->max_policy_pct = (policy->max * 100) / policy->cpuinfo.max_freq; limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100); + limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100, + policy->cpuinfo.max_freq); /* Normalize user input to [min_policy_pct, max_policy_pct] */ limits->min_perf_pct = max(limits->min_policy_pct,
I have a Intel (6,63) processor with a "marketing" frequency (from /proc/cpuinfo) of 2100MHz, and a max turbo frequency of 2600MHz. I can execute cpupower frequency-set -g powersave --min 1200MHz --max 2100MHz and the max_freq_pct is set to 80. When adding load to the system I noticed that the cpu frequency only reached 2000MHZ and not 2100MHz as expected. This is because limits->max_policy_pct is calculated as 2100 * 100 /2600 = 80.7 and is rounded down to 80 when it should be rounded up to 81. This patch adds a DIV_ROUND_UP() which will return the correct value. Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Cc: Len Brown <len.brown@intel.com> Cc: Alexandra Yates <alexandra.yates@intel.com> Cc: Kristen Carlson Accardi <kristen@linux.intel.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: linux-pm@vger.kernel.org Signed-off-by: Prarit Bhargava <prarit@redhat.com> --- drivers/cpufreq/intel_pstate.c | 2 ++ 1 file changed, 2 insertions(+)