Bug 65501

Cc: Rafael and Viresh.

(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.

> 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.

(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 ?

> 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%.

(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.

> 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?

(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.

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%?

(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.

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.

(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..

> 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.

(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.

> 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 :)

(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.

ping Rafael ...

ping Rafael...

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 :)

(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/

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.

Hi, all
[RFC] If there is no objection, I'm planning to send a patch to modify MIN_FREQUENCY_UP_THRESHOLD  to 1.

(In reply to sworddragon2 from comment #21)
> 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.

patch sent to:
https://patchwork.kernel.org/patch/7945041/

Closed as patch applied.

Thanks for sending in the patch so that it got applied. Can't wait to make use of this on the next stable release :)

Just a ping to make sure this doesn't get forgotten (I thought that patches will make it into linux-next more or less fast. Just correct me if I'm wrong).