Re: [External] Re: RFC: offering a standardized (/sys/class) userspace API for selecting system/laptop performance-profiles

[Benjamin Berg <bberg@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3858 bytes --]

On Mon, 2020-09-21 at 11:03 +0200, Elia Devito wrote:
> [SNIP]
> 
> 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)

So I think that trying to put the CPU into a power-efficient state does
make sense. But, it is also a more generic issue.

It reminds me of the LPC talk
  "Improving CPU energy efficiency during i/o bottlenecks"
  https://youtu.be/hJa3YMgEu3M?t=8852
The point is, that what we really want here is to run in the most power
efficient state that gets the job done reliably[1]. It doesn't matter
which exact state it is, all that matters is that applications are
happy with regard to the latencies they see.

In other words, I think the problem here really is power-optimizing
long running tasks that wake up regularly but don't need that much CPU
time overall.

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

Yeah, I have been wondering about that. If you need to meet a certain
power budget (due to thermal limits), then you want to first increase
the power efficiency before doing idle injection (i.e. intel_pstate vs.
intel_powerclamp). But, it seems to me that RAPL already achieves the
best possible behaviour without any need for further interaction. So
setting "performance" in the library should result in a high peak
performance if you have a "bursty" load while also giving optimal
results for long running tasks.

Benjamin

[1] Of course, there are more complexities as to which job is actually
relevant. It would for example make sense to inhibit/slow down
background tasks to prevent them from cutting into the power budget of
the running game. It isn't an easy problem, but should be solvable
using cgroups.

> 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.
> 
> On Thu, 2020-09-17 at 13:22 +0200, Hans de Goede wrote:
> > Elia, Mark, I assume that both of you want to get your patches for this
> > upstream sooner, rather then later. But I think we should put them on
> > hold until we have an agreement on a shared userspace API for this.
> > 
> 
> I could maybe update the patch to expose the interface via debugfs like Mark
> wants to do with lenovo driver and make update later when a common interface
> will be fully defined.
> 
> I would prefer the patch to be merged (at lest the init function) because it
> fix the thermald behaviour whit default thermal profile on fresh boot.
> 
> In the next days I will update the patch and send it in other thread to 
> discuss and evaluate a merge in two steps
> 
> Best Regards
> Elia
> 
> 
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]