On 2020-09-22 6:43 a.m., Hans de Goede wrote:
Hi,
On 9/21/20 11:03 AM, Elia Devito wrote:
Hi all, sorry for response delay I'm very busy at work this period
No problem.
A common interface is surely the best solution, especially because it
allows
to standardize the user-space tools and maybe to integrate its with
desktop,
like Bastien is doing with gnome-power-profiles-daemon or like the
similar tool
plasma-pstate.
I think we should keep separate performance and thermal profiles thus
leaving
the possibility of setting a thermal profile independently of the
performance
profile and vice versa.
Hp implements up to 4 thermal profiles (apparently the same ones that
implement
dell), my patch implements the first 3 profiles which are the ones
supported by
my hardware.
1. HP Recommended -> fan stay off and start at low~medium speed when
necessary
2. Performance -> fan stay off and start at medium~hight speed when
necessary
3. Cool -> fan stay off and start at medium~hight speed when
necessary
4. Quiet -> fan should stay off and start at very low speed if
necessary
for each profile the firmware set also a OEM variable to select DPTF
profile
with the adeguate power limit.
combining these profiles with the performance profiles it is possible
to obtain
the desired performance according to the needs of the moment
e.g.
For gaming purpose when the CPU and GPU share the thermal budget, in
this case
the best solution is to set thermal profile to performance to maximize
the heat
dissipation and the p-state profile to powersave, in this way during
loadings
the cpu gain a performance boost that allow to reduce loading time,
instead,
during gameplay the cpu performance will be limited in favor of the GPU
allowing the maximum framerate to be reached.
(feral had to handle it for its gamemode tool:
https://github.com/FeralInteractive/gamemode/pull/179)
Another opposed particular case could be thermal profile set to quiet and
p-state set to performance, usefull for example to maximizze cpu
performance
in silent ambient room like a library, obviously for CPU-only intesive
tasks
the best solution is to set either thermal and performance profile to
performance.
Basically there are infinite combinations that can be made to obtain
the best
configuration for each situation, to allow this a common interface
should offer
a possibility to:
- Define the list of thermal profiles separately from the performance
ones
- Eventually define a list of on/off attributes (useful for lenovo
lap_mode?)
- Provide a description of them
- Switching between thermal profiles regardless of the performance
profile
A possible solution could be a "slider like" interface for performance
level
and a list of thermal profile.
So I have been thinking about this and performance level and thermal
profile
are really inherently couple to each other. Telling the CPU it can use
25W TPD instead of the default 15W, without also ramping up the cooling is
just going to lead to a whole bunch of thermal throttling.
In a desktop machine with a discrete GPU it is sorta easy, in essence
you have
a GPU performance profile, controlling GPU TPD/turbo behavior and the GPU
fans too match, and a CPU performance profile which likewise controls
the CPU fan profile too match the CPU performance profile.
With laptops with a discrete GPU things become harder because there is a
single shared cooling mechanism. But there you could simply say that
performance-profile = max(gpu-profile, cpu-profile).
I mean telling the GPU and CPU that they can burn a gazillion watts and
then telling the cooling setup to be as quiet as possible, is clearly
not going to end well.
This all assumes that we have some nice way to tell the hardware about
the 3 separate (gpu / cpu / cooling) profiles we want.
But that is not always the case; and often when using a CPU with
integrated GPU they are all tied together.
So my proposal is to have a :
/sys/class/performance-profile
Underneath we can have one or more entries (performance-profile providers)
each one with a performance_level file on the previously suggested 0-100
scale
and a performance_mappings file listing the supported discrete values on
that
scale and some descriptions of those discrete values purely for
informational
purposes.
Besides the performance_level and performance_mappings files I would
also like
to add a "type" sysfs attribute, which can have 1 of 3 values:
"system", "cpu" and "gpu".
So something like the thinkpad_acpi performance levels will be "system",
and
the intel_pstate driver could maybe also register itself here as a "cpu"
type performance-profile provider.
This will allow userspace (if / when it wants to) to do things like put the
CPU in medium/balanced mode while telling the GPU to go full-throttle
for when
playing a game which is clearly GPU limited.
This game scenario of course assumes that we then actually will have a
performance-profile driver for both the CPU and the GPU.
Note I'm still just brainstorming here, but I think that having the
0-100 scale + the type thing should cover all the use-cases we want
to cover.
As always feedback or alternative API proposals are very much welcome.
I was mulling this over and I think the 1 to 100 slider seems awkward -
too many levels and the fine graduation mapping onto somewhat coarse (3,
4 or 5) options doesn't seem to fit well for me. I'm struggling to see
how it fits the tweaking CPU vs GPU vs system - do we end up introducing
multiple sliders - which gets complicated with all the choices? I'm just
not convinced yet.
I'm also not sure about being able to tweak everything too - Linux users
are smart but is it just getting irritating at that point? Power (hah!)
users have plenty of tweaking tools at their disposal if they want to
get into change p-states and tweak every little power option; but this
exercise is aimed at those who want to make simple general changes -
increase the power because they have a build to complete, drop into
quiet mode when watching a movie, or a low power setting when they know
they're not going to be able to charge for a long time. I suspect some
smart person will end up automating all this but that's by the by.
So as a counter proposal: Have the slider choose between some key modes
that we think cover the use cases that people would *want*.
I'd keep the mode list small to avoid it being confusing - more could be
added later if really needed but I'm guessing (and happy to be
corrected) that the majority of activities would fit into just a few
boxes reasonably well.
For instance (I think I get the following from the above):
- low power/Cool
- Quiet
- balance/default
- CPU performance
- GPU performance
The vendors would just choose their optimal firmware setting for that
use case depending on what they have available.
Apart from the GPU performance option that maps pretty well for Lenovo
and I think it maps very nicely for HP. I wanted to squish low power ad
quiet together but that seemed unfair - they are very similar though :)
I'm struggling to think of other use cases that would really
matter...thoughts? Is this *too* simple?
Mark
