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:
signature.asc
Description: This is a digitally signed message part
