[Bug 64261] New: Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[Bug 64261] New: Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

            Bug ID: 64261
           Summary: Intel Pstate driver truncates to pstate instead of
                    rounding to nearest pstate
           Product: Power Management
           Version: 2.5
    Kernel Version: 3.12rc7
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: cpufreq
          Assignee: cpufreq@vger.kernel.org
          Reporter: dsmythies@telus.net
        Regression: No

Created attachment 113151
  --> https://bugzilla.kernel.org/attachment.cgi?id=113151&action=edit
shows rounded pstate and current actual for frequency Vs. requested.

The Intel Pstate driver seems to truncate its calculations to the lower integer
pstate. The suggestion is that it should round to the nearest pstate. Recent
(kernel 3.12RC7) math improvements have made achieving 100% frequency better,
but rounding would make it more robust.

The attachment demonstrates.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #1 from Doug Smythies <dsmythies@telus.net> ---
Created attachment 113231
  --> https://bugzilla.kernel.org/attachment.cgi?id=113231&action=edit
Shows rounded pstate and current actual frequency Vs. requested - Turbo on

Just adding a turbo on version of the same attachment provided in the original
posting, which was with turbo off.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

Dirk Brandewie <dirk.brandewie@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dirk.brandewie@gmail.com

--- Comment #2 from Dirk Brandewie <dirk.brandewie@gmail.com> ---
Can you attach the script you are using for this test?  Is the requested P
state in response to a load?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #3 from Doug Smythies <dsmythies@telus.net> ---
Dirk: The script is the same one as was used and posted back in bug 59481.
However, now that that main issue is fixed, it is rather dense to use that
script in the same way, as it takes about 10 hours. In a few hours I will post
a modified version as there is no reason not to speed it up a lot now.

Yes, the requested Pstate is in response to a full load but both min and max
percent have been set to whatever is shown on the x-axis.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #4 from Dirk Brandewie <dirk.brandewie@gmail.com> ---
So you are trying to emulate the userspace governor here, not really to goal of
intel_pstate but OK :-)

The ability to select a single P state was the intended usage of
{min,max}_pct_perf but allow users to select a floor and ceiling for the range
of available P states.  The absolute meaning percent available performance
changes based on the SKU of the part (p states available).

The driver can only select integer values 16->38 in your turbo-on test case.

The p states are 2.6315789 percent wide in terms of turbo frequency and
2.9411765 percent wide in terms of the non-turbo max on your CPU

.42 * 38 = 15.96
.43 * 38 = 16.34
.44 * 38 = 16.72
.45 * 38 = 17.1

45% is where your test goes from 16->17.

For the 3 percent shelves in the turbo-off case. 
.50 * 34 = 17
.51 * 34 = 17.34
.52 * 34 = 17.68
.53 * 34 = 18.03 (so we are off by 3 percent of a pstate due to truncation)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #5 from Doug Smythies <dsmythies@telus.net> ---
Hi Dirk,

There are cases, i.e. when investigating error in load averages where one wants
to lock the CPU at whatever frequency. I realize it was not the goal of
intel_pstate, but still needs to be allowed for. Regardless, I am merely using
this as a way to easily demonstrate the issue.

".53 * 34 = 18.03 (so we are off by 3 percent of a pstate due to truncation)"
No, I am arguing that it is off by 103 percent of a pstate due to truncation.

I am also arguing that if rounding is used there will never be more than a half
of a pstate discrepancy between desired and actual instead of 1 pstate. I am
also arguing that it will help at the 100% end, where right now it might
struggle to get to 100% on some processors.

For your examples, I am saying it should be:

Turbo:
int(.42 * 38 + 0.5) = 16
int(.43 * 38 + 0.5) = 16
int(.44 * 38 + 0.5) = 17
int(.45 * 38 + 0.5) = 17

Turbo off:
int(.50 * 34 + 0.5) = 17
int(.51 * 34 + 0.5) = 17
int(.52 * 34 + 0.5) = 18
int(.53 * 34 + 0.5) = 18

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #6 from Dirk Brandewie <dirk.brandewie@gmail.com> ---
(In reply to Doug Smythies from comment #5)
> Hi Dirk,
> 
> There are cases, i.e. when investigating error in load averages where one
> wants to lock the CPU at whatever frequency. I realize it was not the goal
> of intel_pstate, but still needs to be allowed for.

It is allowed for clearly you are using the mechanism.  The percentage values
to get to a given frequency are SKU dependent.  We could change it to make
your graph look the way you want it on your system.  Then someone else comes up
and say it goes to the higher P state too soon on their system.

In the normal case where intel_pstate is being used to save enrgy being
conservative is a good thing.

If you can't get to a selected (measured) frequency with the current interface
then that is a bug.


> Regardless, I am merely
> using this as a way to easily demonstrate the issue.
> 
> ".53 * 34 = 18.03 (so we are off by 3 percent of a pstate due to truncation)"
> No, I am arguing that it is off by 103 percent of a pstate due to truncation.

int(.53 * 34 + 0.5) = 18

How is it off by a whole P state?
> 
> I am also arguing that if rounding is used there will never be more than a
> half of a pstate discrepancy between desired and actual instead of 1 pstate.
> I am also arguing that it will help at the 100% end, where right now it
> might struggle to get to 100% on some processors.
> 
> For your examples, I am saying it should be:
> 
> Turbo:
> int(.42 * 38 + 0.5) = 16
> int(.43 * 38 + 0.5) = 16
> int(.44 * 38 + 0.5) = 17
> int(.45 * 38 + 0.5) = 17
> 
> Turbo off:
> int(.50 * 34 + 0.5) = 17
> int(.51 * 34 + 0.5) = 17
> int(.52 * 34 + 0.5) = 18
> int(.53 * 34 + 0.5) = 18

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #7 from Doug Smythies <dsmythies@telus.net> ---
(In reply to Dirk Brandewie from comment #6)
> The percentage
> values to get to a given frequency are SKU dependent.

Yes, of course.

> int(.53 * 34 + 0.5) = 18
> 
> How is it off by a whole P state?

Because it actually goes to 1.7 GHz not 1.8 GHz:
CPU 7 is fully loaded:

doug@s15:~/temp$ cat /sys/devices/system/cpu/intel_pstate/*
53
42
1
doug@s15:~/temp$ cat /sys/devices/system/cpu/cpu7/cpufreq/cpuinfo_cur_freq
1699867

By rounding, we stay away from finite math issues at integer boundaries.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #8 from Dirk Brandewie <dirk.brandewie@gmail.com> ---
This NOT how you pin a single P state. Make max == min with the config above
the driver is free to select any P state between 42-53%.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #9 from Doug Smythies <dsmythies@telus.net> ---
I have done it both ways and get the same result, if the CPU is fully loaded.
All of my tests, until this morning were always done with max == min
But O.K.:

doug@s15:~/temp$ sudo ./set_cpu_turbo_off
doug@s15:~/temp$ echo "53" | sudo tee
/sys/devices/system/cpu/intel_pstate/max_perf_pct
53
doug@s15:~/temp$ echo "53" | sudo tee
/sys/devices/system/cpu/intel_pstate/min_perf_pct
53
doug@s15:~/temp$ cat /sys/devices/system/cpu/intel_pstate/*
53
53
1
doug@s15:~/temp$ cat /sys/devices/system/cpu/cpu7/cpufreq/cpuinfo_cur_freq
1700000

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #10 from Doug Smythies <dsmythies@telus.net> ---
Created attachment 113491
  --> https://bugzilla.kernel.org/attachment.cgi?id=113491&action=edit
Test done with min=max percent and min left at 42 percent

This was the test I did so that I knew I could leave min percent at 42 percent
without an unknown side effect. (as long as CPU 7 was under full load, of
course)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #11 from Doug Smythies <dsmythies@telus.net> ---
Created attachment 113581
  --> https://bugzilla.kernel.org/attachment.cgi?id=113581&action=edit
CPU 7 frequency Vs. requested percent with rounding. Turbo off.

I added generic rounding to intel_pstate.c on the kernel 3.12 build for my test
computer.

This attachment is similar to previous attachments, but with a new line added
using the new code. Turbo off. The two occurrences of the span of 4 percent
samples without a frequency step are still there, just moved. I'll look into
that sometime.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #12 from Doug Smythies <dsmythies@telus.net> ---
Created attachment 113591
  --> https://bugzilla.kernel.org/attachment.cgi?id=113591&action=edit
CPU 7 frequency vs load. Turbo off. With and without rounding.

The load on cpu 7 varies from 0.005 to 0.995 in steps of 0.005 at 10 seconds
per step. The frequency is monitored at 10 Hertz.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #13 from Doug Smythies <dsmythies@telus.net> ---
Created attachment 113601
  --> https://bugzilla.kernel.org/attachment.cgi?id=113601&action=edit
CPU 7 frequency vs load. Turbo on. With and without rounding.

The load on cpu 7 varies from 0.005 to 0.995 in steps of 0.005 at 10 seconds
per step. The frequency is monitored at 10 Hertz.

Test 1 of 2. A subsequent test where the load was held at 0.83 and the
load/sleep frequency was varied from 50 hertz to 300 hertz (graph not posted
herein, as it was uneventful between rounding and no rounding), showed much
less frequency jitter for the un-rounded case. Therefore it was decided to
repeat this test.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #14 from Doug Smythies <dsmythies@telus.net> ---
Created attachment 113611
  --> https://bugzilla.kernel.org/attachment.cgi?id=113611&action=edit
CPU 7 frequency vs load. Turbo on. With and without rounding. 2

The load on cpu 7 varies from 0.005 to 0.995 in steps of 0.005 at 10 seconds
per step. The frequency is monitored at 10 Hertz.

Turbo on test 2 of 2. The significant different for the un-rounded data at the
higher frequencies is not understood. I'll look into it.

Note that gains and setpoints have not been altered, yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #15 from Doug Smythies <dsmythies@telus.net> ---
Created attachment 113621
  --> https://bugzilla.kernel.org/attachment.cgi?id=113621&action=edit
The rounding code.

The changes to the code. Probably some incorrect format.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #16 from Dirk Brandewie <dirk.brandewie@gmail.com> ---
(In reply to Doug Smythies from comment #12)
> Created attachment 113591 [details]
> CPU 7 frequency vs load. Turbo off. With and without rounding.
> 
> The load on cpu 7 varies from 0.005 to 0.995 in steps of 0.005 at 10 seconds
> per step. The frequency is monitored at 10 Hertz.

Are you still setting {min/max}_perf_pct or are we changing horses and talking
about using the driver in "normal' mode?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

--- Comment #17 from Doug Smythies <dsmythies@telus.net> ---
(In reply to Dirk Brandewie from comment #16)
> (In reply to Doug Smythies from comment #12)
> > Created attachment 113591 [details]
> > CPU 7 frequency vs load. Turbo off. With and without rounding.
> > 
> > The load on cpu 7 varies from 0.005 to 0.995 in steps of 0.005 at 10 seconds
> > per step. The frequency is monitored at 10 Hertz.
> 
> Are you still setting {min/max}_perf_pct or are we changing horses and
> talking about using the driver in "normal' mode?

No, I am not setting min=max=whatever.
Yes, I was "changing horses" here. The settings are all default from boot up,
except with respect to turbo on or off. I was wanting to try to demonstrate
improvement using rounding in a real operational sense and as it got closer to
100% frequency. Test 1, turbo on, did show improvement and much less jitter.
However Test 2, turbo on, did not. I still need to go back and investigate why
those two tests, which should have been the same, weren't.
Sorry, I should have been clearer in my description.

I have two methods for loading CPUs to various levels and working/sleeping
frequencies:

One uses a program called "consume", originally from Peter Zijlstra of the
kernel.org sched maintainers. It will apply the desired load at the desired
work/sleep frequency, regardless of the CPU frequency. I.E. it does not respond
to the CPU frequency going up, but rather modifies its work load accordingly to
hold to what was asked for, not like a real system.

The other is a program called "waiter" (the name is from the text book I
started it from). It will spin out the desired number of processes at the
desired load at the desired work/sleep frequency, but what it actually does
depends on the CPU frequency and number of running processes. I.E. it responds
to the CPU frequency going up by getting its work done faster, just like a real
system. The user interface for waiter is NOT good, and I tend to use another
program to create scripts to provide operational parameters.

I used "consume" for these graphs.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 64261] Intel Pstate driver truncates to pstate instead of rounding to nearest pstate

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=64261

Lan Tianyu <tianyu.lan@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tianyu.lan@intel.com
           Assignee|cpufreq@vger.kernel.org     |dirk.brandewie@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.