fix low performance when charging #34
Conversation
|
I introduced this change recently, as at the beginning I was of same opinion as you. This was initially suggested on Reddit, and thinking about it made a lot sense. Hence I made this changes as first step towards this goal. Because if you have a really low load, why do you need CPU running at its absolute max. All it'll do in this case is save power/electricity used which isn't much on a single computer. But image how much power could be saved if |
|
I'll test some changes and inform you. With that type of change that has been introduced by you, I haven't a good relationship with GNOME, it stutters and lags. |
|
Continuing the test of that PR, and will make some changes when necessary. If you have a better idea, share with me. There is a really performance drop when using that DE with your changes. |
This is good, exactly what I was also thinking at this point. I'll also do some testing using these change and will give you my feedback. I also use GNOME, and I have 0 performance issues with existing implementation in GNOME or anywhere else. |
|
|
|
Sorry for delayed response from my side, been very busy last couple of days. I'll thoroughly review this tomorrow. |
|
Take your time, I’m also experimenting the variables. Also thinking to implement the governor-turbo boost changing based on temperature, but, well I think this should not be belong there, I mean this PR. |
auto-cpufreq.py
Outdated
| if load1m >= cpus * (3 / 5): | ||
| print("Setting to use: \"performance\" governor") | ||
| s.run("cpufreqctl --governor --set=performance", shell=True) | ||
|
|
There was a problem hiding this comment.
I'm not sure about switching to "performance" while in "powersave" mode, regardless of the load/CPU usage.
Only thing that would give us valuable metric would be to test how much battery would be used on battery while in "peformance" mode on battery vs given same conditions in "powersave". I believe more battery will be used in "performance".
Hence the reason why I went with option to turn turbo boost on instead, which should handle the load.
Also, based on what criteria did you come up with this number: load1m >= cpus * (3 / 5)
There was a problem hiding this comment.
I just want to sure about the user's CPU load is more than 'more than the average'. Because if there is a very high load, even though the discharging, we should provide to the user the performance governor. The 3/5 is changeable though.
There was a problem hiding this comment.
After thinking about this for couple of days now, let's do this. Currently auto-cpufreq is really "trigger ready". In sense that it will easily switch governors and turn on/off turbo.
I like what you did here with calculations, but instead of switching to "performance" governor while on battery, let it turn on/off turbo instead depending on load/cpu usage while in powersave (battery discharging).
This way we'll have refined way of turning turbo on/off and tool being less of "trigger friendly".
There was a problem hiding this comment.
@AdnanHodzic I made following changes about your explanation. Could you have a chance for looking at it?
There was a problem hiding this comment.
Right, but currently as part of set_performance function it's still set to change governors, which is not good.
print("Setting to use: \"powersave\" governor")
s.run("cpufreqctl --governor --set=powersave", shell=True)
print("Load optimal, setting turbo boost: on")
s.run("echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo", shell=True)
Which results in situations like these:
Battery is: charging
Total CPU usage: 2.0 %
Total system load: 0.24
Setting to use: "powersave" governor
Load optimal, setting turbo boost: on
Why is turbo on if load is optimal? Ass I said, let's not change governors if it's charging (performance) or discharging (powersave).
Once in one of those 2 governors, let's just turn turbo on/off based on more refined cpu usage/system load.
There was a problem hiding this comment.
Well, I think if there is no or small load of CPU, pushing the clock to the best base clock freq is not necessary, which is performance governor does. If we are very keen on power saving when low load, I think that way is more accurate because powersave governor could lower the freq of the CPU and if necessary, it will push the clock freq to the higher.
There was a problem hiding this comment.
I'm sorry, but I don't agree. There is "small load", let's say you're on battery power and hence in powersave, you're watching 1 minute 8K Youtube video. Turbo kicks in, does the heavy load once the load is gone, it turns off turbo. Battery was preserved to its max, while CPU temperature/fans stayed at their optimal levels and you got the performance that you needed at that moment.
Only exception, where I agree with you that app should switch from powersave to performance (while on battery) is if we could figure out some kind of algorithm or equation where it detects when it's really necessary. For example, if load and cpu usage (and in future CPU temp/fan speed) are running high for >= 5 minutes, besides turbo also switch the governor from powersave to performance.
Otherwise if you have the app switching to performance while on battery battery for every little thing, you'll get performance you needed, but battery life will suffer just as it would without this tool, which then defeats its purpose. Goal is to get performance you need, while saving the battery at the same time, and this is where things get tricky.
But, these are things that can be done at later stages. Right now, I think it would be the best if we could refine the current settings under which "turbo" is turned on/off and make the app less "trigger friendly", which you already did with i.e: if load1m > cpus / 7:
This would be the first "baby" steps towards the final goal which I described here, and are the changes I highly welcome.
There was a problem hiding this comment.
For example, if load and cpu usage (and in future CPU temp/fan speed) are running high for >= 5 minutes, besides turbo also switch the governor from powersave to performance.
That looks easily doable.
Other than, I have already reverted what did you say of "performance governor when battery" situation. I think you understand my last comment wrong. I said these words for "powersave governor with turbo boost capability -it doesn't mean we push the clock to highest- with when charging". Could you have a chance for giving an explanation for your thoughts? Why performance with turbo boost capability off (that means we are pushing the clock to base speed which is the 1.6 GHz for my case) instead of powersave with turboboost capability enabled (no low load -> 0.8-1.2 GHz, if load it increases but it drops quickly when not necessary)?
|
About the comment that you did, sorry for the late reply. I have been very busy recently and as soon as I am free, I’ll be back there. |
No worries, take your time. |
|
@validatedev maybe changes we agree on from this PR should also go as part of snap branch, just as it was the case with #40 I would really like to see the "calculations" part to also be merged, as they make the tool less "trigger friendly". Basically it's all good, except changing the governor to Think about it and if you have time please feel free to make a new MR, there's still time as I'm waiting for some interface related changes to be made from Ubuntu side. |
|
@AdnanHodzic OK, I'll make these changes that you're referring today. Closing this PR. |
I think there isn't any necessity for limiting the performance of CPU when the PC on charging status. In case of config file improvement, the if-else block isn't touched.