[Bug 65501] New: Blind angle of 1% between up_threshold and down_threshold

[Bug 65501] New: Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

            Bug ID: 65501
           Summary: Blind angle of 1% between up_threshold and
                    down_threshold
           Product: Power Management
           Version: 2.5
    Kernel Version: Ubuntu 3.12.0-3.9-generic 3.12.1
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: cpufreq
          Assignee: cpufreq@vger.kernel.org
          Reporter: sworddragon2@aol.com
        Regression: No

The lowest value that /sys/devices/system/cpu/cpufreq/ondemand/up_threshold can
contain is 11 while the implicit configuration down_threshold will be
statically set to 10. But I'm thinking that it would be correct if up_threshold
could be set to 10 too as this wouldn't cause any collision. up_threshold would
scale if the cpu core reaches 10% or more of cpu usage (>=) and down_threshold
would scale if the cpu core reaches less than 10% of cpu usage (<).

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

Alan <alan@lxorguk.ukuu.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alan@lxorguk.ukuu.org.uk
     Kernel Version|Ubuntu 3.12.0-3.9-generic   |3.12.0-3.9
                   |3.12.1                      |

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |rjw@rjwysocki.net,
                   |                            |tianyu.lan@intel.com,
                   |                            |viresh.kumar@linaro.org

--- Comment #1 from Lan Tianyu <tianyu.lan@intel.com> ---
Cc: Rafael and Viresh.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #2 from Viresh Kumar <viresh.kumar@linaro.org> ---
(In reply to sworddragon2 from comment #0)
> The lowest value that /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
> can contain is 11 while the implicit configuration down_threshold will be
> statically set to 10.

I got a bit confused. You are talking about up_threshold and down_threshold for
ondemand governor. Whereas down_threshold isn't there for ondemand governor.
Its only there for conservative governor. And there are no such max/min limits
available there.

So more clarification required from your side on this issue.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #3 from sworddragon2@aol.com ---
> So more clarification required from your side on this issue.

As far as I know some time ago the default value of down_threshold was set to
10 and after it was removed from procfs it was still set internally to 10. Just
try to set up_threshold to 10 or lower - it will be refused. So there is still
a min limit of 11 for up_threshold.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #4 from Viresh Kumar <viresh.kumar@linaro.org> ---
(In reply to sworddragon2 from comment #3)
> As far as I know some time ago the default value of down_threshold was set

Which governor are you talking about? Ondemand doesn't have down_threshold.

> to 10 and after it was removed from procfs it was still set internally to
> 10. Just try to set up_threshold to 10 or lower - it will be refused. So
> there is still a min limit of 11 for up_threshold.

That's the value of MIN_FREQUENCY_UP_THRESHOLD (11) and so it will fail for
values <= 10..

So, what do you want to change now ?

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #5 from sworddragon2@aol.com ---
> Which governor are you talking about? Ondemand doesn't have down_threshold.

I'm talking about ondemand and it had in the past down_threshold.


> So, what do you want to change now ?

Just for clarification: If there is no down_threshold anymore how will the cpu
scale down its frequency? I was simply assuming that this will happen now at
10%.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #6 from Viresh Kumar <viresh.kumar@linaro.org> ---
(In reply to sworddragon2 from comment #5)
> I'm talking about ondemand and it had in the past down_threshold.

I don't think it ever had it. I checked 2.6.30 and 3.0.. they don't have it. :)

> Just for clarification: If there is no down_threshold anymore how will the
> cpu scale down its frequency? I was simply assuming that this will happen
> now at 10%.

No, that's not right. We will go to max frequency if load has increased over
up_threshold, otherwise freq will be proportional to load.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #7 from sworddragon2@aol.com ---
> I don't think it ever had it. I checked 2.6.30 and 3.0.. they don't have it. :)

Very interestingly.


> No, that's not right. We will go to max frequency if load has increased over up_threshold, otherwise freq will be proportional to load.

Thanks, this makes things much clearer (especially if I think on another
report). This will now leave a simple question: Why is
MIN_FREQUENCY_UP_THRESHOLD not 1?

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #8 from Viresh Kumar <viresh.kumar@linaro.org> ---
(In reply to sworddragon2 from comment #7)
> Why is MIN_FREQUENCY_UP_THRESHOLD not 1?

That would be foolish :)

This will make CPU run on max frequency all the time.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #9 from sworddragon2@aol.com ---
Are you sure? As much as I understand this wouldn't the cpu only scale up if it
reaches 1% of cpu usage? Wouldn't the frequency then scale down as soon as the
system is in idle with ~0%?

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #10 from Viresh Kumar <viresh.kumar@linaro.org> ---
(In reply to sworddragon2 from comment #9)
> Are you sure? As much as I understand this wouldn't the cpu only scale up if
> it reaches 1% of cpu usage? Wouldn't the frequency then scale down as soon
> as the system is in idle with ~0%?

CPU load would be less than 1% only when CPU is idle and at that time CPU will
move to some lop power mode and will stop executing anything due to CPUIdle.
Hence governors will not get a chance of changing freq to lower values.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #11 from sworddragon2@aol.com ---
Are you sure that the cpu can be at a state of 0.9% there it can't scale down
the frequency anymore? Such a behavior would look extremely strange to me.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #12 from Viresh Kumar <viresh.kumar@linaro.org> ---
(In reply to sworddragon2 from comment #11)
> Are you sure that the cpu can be at a state of 0.9% there it can't scale
> down the frequency anymore? Such a behavior would look extremely strange to
> me.

There is no floating point division here :)
And even if we do that, we don't really need to take care of loads lesser than
1%, that's too small..

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #13 from sworddragon2@aol.com ---
> There is no floating point division here :)

Than lets repeat this text with MIN_FREQUENCY_UP_THRESHOLD as 2. But...


> And even if we do that, we don't really need to take care of loads lesser than > 1%, that's too small..

... we are moving now into the correct direction :)
This is the point that disturbs me. We are setting a fixed minimum limit of 11
while there is no logical reason to do this. Lets make the hypothetical
assumption that MIN_FREQUENCY_UP_THRESHOLD could be set to 1:

- Current systems wouldn't be affected as they have already a value >= 11.
- New systems with a default kernel would keep still the default value that is
>= 11.

So there is no disadvantage for these systems. But users now have the advantage
that they can make there own decision how low they want to go.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #14 from Viresh Kumar <viresh.kumar@linaro.org> ---
(In reply to sworddragon2 from comment #13)
> This is the point that disturbs me. We are setting a fixed minimum limit of
> 11 while there is no logical reason to do this.

This must be based on the reasoning that we don't have to go to max freq for
loads as low as 10%. That sounds reasonable too, atleast to me. If you want
such system where you want to go to max freq as soon as there is any load then
better use performance governor. Otherwise what's currently in there looks good
to me. I would actually say even 10% is a very low value of min up_threshold.
It could have been more :)

Don't know what Rafael have to say on this.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #15 from sworddragon2@aol.com ---
> This must be based on the reasoning that we don't have to go to max freq for loads as low as 10%.

Except the process splits up in several "small" threads. For example on Flash I
get only half of the performance with the default value. Either I could use the
performance governor to solve this issue (and loose the ability to save power)
or lower MIN_FREQUENCY_UP_THRESHOLD.

But I would still prefer to let the user decide what he wants to use (there
could always pop up new cases for users that want a lower value). Normally
having such a freedom was the choice I have abandoned Windows over 3 years ago
:)

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #16 from Viresh Kumar <viresh.kumar@linaro.org> ---
(In reply to sworddragon2 from comment #15)
> Normally having such a freedom was the choice I have abandoned Windows over 3
> years ago :)

I don't want you to go to windows again :) 

@Rafael: What do you say? Probably we can lower the MIN possible value of
UP_THRESHOLD, that wouldn't affect any existing user.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #17 from Lan Tianyu <tianyu.lan@intel.com> ---
ping Rafael ...

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

Zhang Rui <rui.zhang@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rui.zhang@intel.com

--- Comment #18 from Zhang Rui <rui.zhang@intel.com> ---
ping Rafael...

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #19 from sworddragon2@aol.com ---
I'm still noticing on some games random performance drops if they are threading
too much. I think it is time for another ping to get this more or less done :)

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #20 from Chen Yu <yu.c.chen@intel.com> ---
(In reply to sworddragon2 from comment #19)
> I'm still noticing on some games random performance drops if they are
> threading too much. I think it is time for another ping to get this more or
> less done :)
Tested with MIN_FREQUENCY_UP_THRESHOLD = 1, seems no problem under different
cpu load, but if  set with CONFIG_HZ_PERIODIC should apply this one first:
https://patchwork.kernel.org/patch/7859871/

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

--- Comment #21 from sworddragon2@aol.com ---
sworddragon@ubuntu:~$ cat /boot/config-4.3.0-4-generic | grep
CONFIG_HZ_PERIODIC
# CONFIG_HZ_PERIODIC is not set

Ubuntu seems to not set this option on the desktop version. Also I'm noticing
this performance issue rarely. For example I remember to have seen this issue
some time ago on Loot Heroes and some other games I don't remember well
anymore. They worked much better from changing all 6 cores to the performance
governor (was ondemand with up_threshold on 11 before). And a short time ago I
have noticed this performance drop on Bullet Heaven 2 but it was only a short
test. If I could I would simply set up_threshold to 1 to be sure to really
eliminate any race condition here as much as possible.

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

[Bug 65501] Blind angle of 1% between up_threshold and down_threshold

[bugzilla-daemon]

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

Zhang Rui <rui.zhang@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|cpufreq@vger.kernel.org     |yu.c.chen@intel.com

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