[Ksummit-discuss] [TECH TOPIC] System-wide interface to specify the level of PM tuning

Daniel Vetter daniel.vetter at ffwll.ch
Sun Jul 12 10:01:27 UTC 2015


On Fri, Jul 10, 2015 at 7:25 PM, Kevin Hilman <khilman at kernel.org> wrote:
> "Rafael J. Wysocki" <rjw at rjwysocki.net> writes:
>
>> On Monday, July 06, 2015 01:49:45 PM Iyer, Sundar wrote:
>
> [...]
>
>>> Is a "single setting somewhere" even appropriate? It is actually the intelligence
>>> needed vs executing the actions?
>>
>> For one example, the default for most of the device/.../power/control files in
>> sysfs is "on" (meaning no runtime PM) while it might be "auto" (use runtime PM
>> if you can).  Making that change for everybody in one go may lead to various
>> issues (that may be regarded as regressions then), but if we made it configurable,
>> people might choose to make that change for themselves if they wanted to.
>
> I'd be very supportive of some default knob (or cmdline option) to favor
> energy efficiency.  For runtime PM, I suspect the resulting performance
> regressions are mostly (relatively) simple fixes, like enabling
> autosuspend, etc.
>
> Also, having a system-wide way to enable this mode would also enable us
> to find/report these bugs/regressions in a way that would be easily
> repeatable.  With the current pile of knobs/tunables, it's often very
> hard to reproduce problems others may be seeing.

My approach in drm/i915 is that there's just one default config and
that's the well-tuned one. Maybe gfx is special, but with todays
power-envelope constrained chips it's not a question of performance
_or_ power efficiency, but always _and_: Enabling power saving
features improves performance. And where it doesn't we just fix those
problems with smarter code (since usually the performance regressions
happen when you ping-pong too badly between different levels, or are
stuck for too long in a given power saving level). The other reason
for that approach is that gfx is complex and we just can't test
arbitrary combinations of options - hence we auto-taint the kernel if
users touch anything at all.

The downside is that you'll get more bug reports and can't hide from
them easily ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the Ksummit-discuss mailing list