Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

switch between cpu power configurations depending on the current workload #7

Open
monarc99 opened this issue Oct 28, 2021 · 4 comments
Assignees
Labels
question Further information is requested

Comments

@monarc99
Copy link

I would like to test to switch power configs on current workload or something similar.

e.g. mpv Video Player

if it plays a video and use hardware decoding, it does not need much cpu power -> powersave profile
But if it has to play a 8K AV1 Video, no HW support for AV1, it falls back to software decoding -> performance profile

Do you plan to add switching on usage? (i am not sure, if usage is the best value for it - e.g. single core program, that utilise only 1 core with 100%, other 1-2%)

@monarc99 monarc99 added the question Further information is requested label Oct 28, 2021
@Haptein
Copy link
Owner

Haptein commented Oct 28, 2021

Right now I'm implementing a system to track performance states across time (SystemStatus branch) which is needed to implement this kind of features.

Do you plan to add switching on usage?

I am interested in implementing this kind of feature. It would be simple to implement a system that switches gears depending on per core cpu load, for example switching policies or governors depending of load. The complexity of it comes in designing it in a way that is simple to configure and is available to multiple scaling drivers. I was thinking on dynamically changing the maximum frequency allowed instead of governors/policy, what do you think about this approach in the context of your usecases? Still, I'm all for experimenting 🧪

@monarc99
Copy link
Author

So always performance gov, but with limited freq? Turbo?

I have two usecases.

On AC - save power if idle, but performance is more important. Even on lower usage, switch to max freq/policy/governor. Really quick.
On BAT - save power. I would change max. freq only on really high usage (on several cores?).

@monarc99
Copy link
Author

And i think you can expect the Power Profiles Daemon on every KDE/Gnome system in the future.
Maybe powerplan could use it. e.g. automatic switching the power profile daemon.

@Haptein
Copy link
Owner

Haptein commented Oct 28, 2021

So always performance gov, but with limited freq? Turbo?

I was thinking on having a "dynamic_frequency_limiter" or something similar as a toggle, available just like any other profile entry. So people can experiment and find what works best for different preference/use cases(and with enough feedback documenting a guide with recommendations sounds reasonable).

And i think you can expect the Power Profiles Daemon on every KDE/Gnome system in the future. Maybe powerplan could use it. e.g. automatic switching the power profile daemon.

I think ppd it's a nice project, but in the context of powerplan I worry about the interference between the two. I think ppd's approach ppd is a bit simplistic compared to what I'd personally like to use as it currently only offers a couple presets, I'd have to see a roadmap tho. With intel_pstate for example, ppd only switches policies, and it ought to use the same sysfs interface used here. The only reason I see to interact with ppd (at least right now) is to make sure it's in line with the current profile applied by powerplan.

On the other hand, I had the idea of releasing a rust rewrite of this project once it's codebase stabilizes, so I guess submitting some code to ppd in the future is not out of the question either, how far off in the future I don know tho.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants