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

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

[Rafael J. Wysocki]

Hi All,

This is a re-occuring theme, but we discussed it last month during LinuxCon
Japan with Kristen, Grant and other people and pretty much the only conclusion
we could reach was to propose it as the KS topic, so here it goes.

As systems get more and more complex and more and more internally integrated
over time, every new generation of them requires an increased amount of tuning
to achieve satisfactory balance between energy usage and performance.  You need
to know what to tune and how to do that, it needs to be done from user space or
requires special Kconfig options to be set (or even out-of-the-tree patches to
be applied in extreme cases) and so on.  All that becomes more and more esoteric
and quite frankly I'm not sure how many users are able to do that on their new
systems.

That leads to a question whether or not a global interface (sysfs-based,
command line etc.) could be added to the kernel that might be used to make a
certain amount of the tuning happen already at the kernel level.  For example,
it might change the default runtime PM control setting for all devices from
"on" to "auto", automatically enable other runtime power management features
available from various bus types (SATA link power management, USB LPM, others)
and generally enable power management techiques disabled by default because
enabling them may lead to performance regressions.

So do we need such an interface?  If not, why not?  If so, how should it be
designed, what should it cover etc.?

Thanks,
Rafael

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

[Josh Triplett]

On Mon, Jul 06, 2015 at 02:22:02AM +0200, Rafael J. Wysocki wrote:
> This is a re-occuring theme, but we discussed it last month during LinuxCon
> Japan with Kristen, Grant and other people and pretty much the only conclusion
> we could reach was to propose it as the KS topic, so here it goes.
> 
> As systems get more and more complex and more and more internally integrated
> over time, every new generation of them requires an increased amount of tuning
> to achieve satisfactory balance between energy usage and performance.  You need
> to know what to tune and how to do that, it needs to be done from user space or
> requires special Kconfig options to be set (or even out-of-the-tree patches to
> be applied in extreme cases) and so on.  All that becomes more and more esoteric
> and quite frankly I'm not sure how many users are able to do that on their new
> systems.
> 
> That leads to a question whether or not a global interface (sysfs-based,
> command line etc.) could be added to the kernel that might be used to make a
> certain amount of the tuning happen already at the kernel level.  For example,
> it might change the default runtime PM control setting for all devices from
> "on" to "auto", automatically enable other runtime power management features
> available from various bus types (SATA link power management, USB LPM, others)
> and generally enable power management techiques disabled by default because
> enabling them may lead to performance regressions.
> 
> So do we need such an interface?  If not, why not?  If so, how should it be
> designed, what should it cover etc.?

Performance regressions alone aren't a good reason to disable power
management by default.  As I understand it, several power management
features are disabled by default because they tend to break things and
we don't have an enormous whitelist or blacklist; for instance, USB LPM.
If there's a power management feature we're not enabling by default
because it decreases performance by epsilon, let's change that.

If someone cares so much about performance that they're willing to burn
a disproportionate amount of power to get it (meaning that they care
more about performance than performance per watt, and can't just solve
the problem by throwing more systems at it instead), then it doesn't
seem unreasonable to reconfigure the kernel for that.  (Though if there
are out-of-tree patches needed to enable that configuration, by all
means let's merge those.)  But let's be consistent in our defaults, and
given the huge number of people who may never change the defaults, I'd
advocate power management by default.  (A distribution could always
offer a kernel flavor for people who want performance at all costs.)

- Josh Triplett

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

[Rafael J. Wysocki]

On Sunday, July 05, 2015 06:21:25 PM Josh Triplett wrote:
> On Mon, Jul 06, 2015 at 02:22:02AM +0200, Rafael J. Wysocki wrote:
> > This is a re-occuring theme, but we discussed it last month during LinuxCon
> > Japan with Kristen, Grant and other people and pretty much the only conclusion
> > we could reach was to propose it as the KS topic, so here it goes.
> > 
> > As systems get more and more complex and more and more internally integrated
> > over time, every new generation of them requires an increased amount of tuning
> > to achieve satisfactory balance between energy usage and performance.  You need
> > to know what to tune and how to do that, it needs to be done from user space or
> > requires special Kconfig options to be set (or even out-of-the-tree patches to
> > be applied in extreme cases) and so on.  All that becomes more and more esoteric
> > and quite frankly I'm not sure how many users are able to do that on their new
> > systems.
> > 
> > That leads to a question whether or not a global interface (sysfs-based,
> > command line etc.) could be added to the kernel that might be used to make a
> > certain amount of the tuning happen already at the kernel level.  For example,
> > it might change the default runtime PM control setting for all devices from
> > "on" to "auto", automatically enable other runtime power management features
> > available from various bus types (SATA link power management, USB LPM, others)
> > and generally enable power management techiques disabled by default because
> > enabling them may lead to performance regressions.
> > 
> > So do we need such an interface?  If not, why not?  If so, how should it be
> > designed, what should it cover etc.?
> 
> Performance regressions alone aren't a good reason to disable power
> management by default.  As I understand it, several power management
> features are disabled by default because they tend to break things and
> we don't have an enormous whitelist or blacklist; for instance, USB LPM.
> If there's a power management feature we're not enabling by default
> because it decreases performance by epsilon, let's change that.

Problem is in many cases it is difficult to estimate the epsilon in advance,
so it is regarded as "dangerous" to change the default for everybody.

> If someone cares so much about performance that they're willing to burn
> a disproportionate amount of power to get it (meaning that they care
> more about performance than performance per watt, and can't just solve
> the problem by throwing more systems at it instead), then it doesn't
> seem unreasonable to reconfigure the kernel for that.  (Though if there
> are out-of-tree patches needed to enable that configuration, by all
> means let's merge those.)  But let's be consistent in our defaults, and
> given the huge number of people who may never change the defaults, I'd
> advocate power management by default.  (A distribution could always
> offer a kernel flavor for people who want performance at all costs.)

The current situation, though, is that we tend to choose "safe" defaults that
favor performance and to switch over to power-oriented you need to do all of
the tuning I was talking about.  So the idea is to have a single place you
can use to tell the kernel to "tune for energy-efficiency".

Thanks,
Rafael

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

[NeilBrown]

On Mon, 06 Jul 2015 02:22:02 +0200 "Rafael J. Wysocki"
<rjw@rjwysocki.net> wrote:

> Hi All,
> 
> This is a re-occuring theme, but we discussed it last month during LinuxCon
> Japan with Kristen, Grant and other people and pretty much the only conclusion
> we could reach was to propose it as the KS topic, so here it goes.
> 
> As systems get more and more complex and more and more internally integrated
> over time, every new generation of them requires an increased amount of tuning
> to achieve satisfactory balance between energy usage and performance.  You need
> to know what to tune and how to do that, it needs to be done from user space or
> requires special Kconfig options to be set (or even out-of-the-tree patches to
> be applied in extreme cases) and so on.  All that becomes more and more esoteric
> and quite frankly I'm not sure how many users are able to do that on their new
> systems.
> 
> That leads to a question whether or not a global interface (sysfs-based,
> command line etc.) could be added to the kernel that might be used to make a
> certain amount of the tuning happen already at the kernel level.  For example,
> it might change the default runtime PM control setting for all devices from
> "on" to "auto", automatically enable other runtime power management features
> available from various bus types (SATA link power management, USB LPM, others)
> and generally enable power management techiques disabled by default because
> enabling them may lead to performance regressions.
> 
> So do we need such an interface?  If not, why not?  If so, how should it be
> designed, what should it cover etc.?
> 

This sounds like an important topic, but I don't think I quite
understand the question.
We already have ".../power/runtime_enabled" and various other tunables.
What more could you need in a kernel interface?

I can see that much more than an interface is needed - we need a tool
that makes use of that interface.
Maybe a database of different systems together with tuning settings for
different goals.
Then some tools detects the particular hardware it is running on, and
applies the tuning rules.

(a tiny bit like a devicetree database which contains configuration
rules).

Or have I missed the point completely?

Thanks,
NeilBrown

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

[Rafael J. Wysocki]

On Monday, July 06, 2015 11:40:17 AM NeilBrown wrote:
> On Mon, 06 Jul 2015 02:22:02 +0200 "Rafael J. Wysocki"
> <rjw@rjwysocki.net> wrote:
> 
> > Hi All,
> > 
> > This is a re-occuring theme, but we discussed it last month during LinuxCon
> > Japan with Kristen, Grant and other people and pretty much the only conclusion
> > we could reach was to propose it as the KS topic, so here it goes.
> > 
> > As systems get more and more complex and more and more internally integrated
> > over time, every new generation of them requires an increased amount of tuning
> > to achieve satisfactory balance between energy usage and performance.  You need
> > to know what to tune and how to do that, it needs to be done from user space or
> > requires special Kconfig options to be set (or even out-of-the-tree patches to
> > be applied in extreme cases) and so on.  All that becomes more and more esoteric
> > and quite frankly I'm not sure how many users are able to do that on their new
> > systems.
> > 
> > That leads to a question whether or not a global interface (sysfs-based,
> > command line etc.) could be added to the kernel that might be used to make a
> > certain amount of the tuning happen already at the kernel level.  For example,
> > it might change the default runtime PM control setting for all devices from
> > "on" to "auto", automatically enable other runtime power management features
> > available from various bus types (SATA link power management, USB LPM, others)
> > and generally enable power management techiques disabled by default because
> > enabling them may lead to performance regressions.
> > 
> > So do we need such an interface?  If not, why not?  If so, how should it be
> > designed, what should it cover etc.?
> > 
> 
> This sounds like an important topic, but I don't think I quite
> understand the question.
> We already have ".../power/runtime_enabled" and various other tunables.
> What more could you need in a kernel interface?

The problem is that the defaults for all of those tunables are performance-oriented,
so you need to flip many of them (if not all) to become power-oriented.

That usually mean flipping a number of knobs every time you boot the system.

> I can see that much more than an interface is needed - we need a tool
> that makes use of that interface.

That is one possible approach, but that tool would need to be developed in
a lockstep with the kernel anyway, so it knows about all of the new features
added to the kernel over time that have non-trivial power vs performance
characteristics.

> Maybe a database of different systems together with tuning settings for
> different goals.
> Then some tools detects the particular hardware it is running on, and
> applies the tuning rules.
> 
> (a tiny bit like a devicetree database which contains configuration
> rules).
> 
> Or have I missed the point completely?

No, I don't think you have missed it, but then most of subsystems and drivers
in the kernel know what it means to be "power-friendly", so they should be able
to choose their defaults on the basis of one single setting somewhere.

Thanks,
Rafael

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

[Iyer, Sundar]

> -----Original Message-----
> From: ksummit-discuss-bounces@lists.linuxfoundation.org [mailto:ksummit-
> discuss-bounces@lists.linuxfoundation.org] On Behalf Of Rafael J. Wysocki
> Sent: Monday, July 6, 2015 7:12 AM
> To: NeilBrown
> Cc: Grant Likely; Brown, Len; Alan Stern; Kristen Carlson Accardi; ksummit-
> discuss@lists.linuxfoundation.org
> Subject: Re: [Ksummit-discuss] [TECH TOPIC] System-wide interface to specify
> the level of PM tuning
> 

> >
> > (a tiny bit like a devicetree database which contains configuration
> > rules).
> >
> > Or have I missed the point completely?
> 
> No, I don't think you have missed it, but then most of subsystems and drivers in
> the kernel know what it means to be "power-friendly", so they should be able to
> choose their defaults on the basis of one single setting somewhere.

Is a "single setting somewhere" even appropriate? It is actually the intelligence needed vs executing the actions?

Cheers!

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

[Rafael J. Wysocki]

On Monday, July 06, 2015 01:49:45 PM Iyer, Sundar wrote:
> > -----Original Message-----
> > From: ksummit-discuss-bounces@lists.linuxfoundation.org [mailto:ksummit-
> > discuss-bounces@lists.linuxfoundation.org] On Behalf Of Rafael J. Wysocki
> > Sent: Monday, July 6, 2015 7:12 AM
> > To: NeilBrown
> > Cc: Grant Likely; Brown, Len; Alan Stern; Kristen Carlson Accardi; ksummit-
> > discuss@lists.linuxfoundation.org
> > Subject: Re: [Ksummit-discuss] [TECH TOPIC] System-wide interface to specify
> > the level of PM tuning
> > 
> 
> > >
> > > (a tiny bit like a devicetree database which contains configuration
> > > rules).
> > >
> > > Or have I missed the point completely?
> > 
> > No, I don't think you have missed it, but then most of subsystems and drivers in
> > the kernel know what it means to be "power-friendly", so they should be able to
> > choose their defaults on the basis of one single setting somewhere.
> 
> 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.

Thanks,
Rafael

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

[Jiri Kosina]

On Mon, 6 Jul 2015, Rafael J. Wysocki wrote:

> 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), 

I don't believe that the current default settings are set the way they are 
set because we intentionally want to prefer performance to power 
efficiency. The real problem is that it's really the only "safe" default, 
because turning power-management features on is likely to cause 
unpredictable issues (being it either real bugs in code, or just bad user 
experience stemming from unexpected system behavior).

Such as suspended keyboard losing first keypress during wakeup (very 
common). Or wireless power management not working properly between the 
client and AP. Etc etc.

-- 
Jiri Kosina
SUSE Labs

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

[Rafael J. Wysocki]

On Tuesday, July 07, 2015 09:53:44 AM Jiri Kosina wrote:
> On Mon, 6 Jul 2015, Rafael J. Wysocki wrote:
> 
> > 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), 
> 
> I don't believe that the current default settings are set the way they are 
> set because we intentionally want to prefer performance to power efficiency.

No, this is not the intent, but having those defaults favors performance as
a consequence (and increasingly so as the integration of systems increases).

> The real problem is that it's really the only "safe" default, 
> because turning power-management features on is likely to cause 
> unpredictable issues (being it either real bugs in code, or just bad user 
> experience stemming from unexpected system behavior).
> 
> Such as suspended keyboard losing first keypress during wakeup (very 
> common). Or wireless power management not working properly between the 
> client and AP. Etc etc.

Agreed.

On the other hand, though, there are systems without those problems and their
users should be able to choose a more power-oriented behavior relatively
easily.

Thanks,
Rafael

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

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@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.

Kevin

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

[Daniel Vetter]

On Fri, Jul 10, 2015 at 7:25 PM, Kevin Hilman <khilman@kernel.org> wrote:
> "Rafael J. Wysocki" <rjw@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

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

[Rafael J. Wysocki]

On Sunday, July 12, 2015 12:01:27 PM Daniel Vetter wrote:
> On Fri, Jul 10, 2015 at 7:25 PM, Kevin Hilman <khilman@kernel.org> wrote:
> > "Rafael J. Wysocki" <rjw@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.

However, there are places in the kernel where there is a real tradeoff between
power and performance (or power and capacity in general) and there are places
that tend to keep conservative settings for fear of exposing latent bugs to
a wide community of users.

Those might benefit from allowing the users to relax the settings globally
if they want to.

Thanks,
Rafael

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

[Daniel Vetter]

On Tue, Jul 14, 2015 at 1:07 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> However, there are places in the kernel where there is a real tradeoff between
> power and performance (or power and capacity in general) and there are places
> that tend to keep conservative settings for fear of exposing latent bugs to
> a wide community of users.
>
> Those might benefit from allowing the users to relax the settings globally
> if they want to.

Well that's the approach I don't like personally. Essentially we
should be the experts on what works and what doesn't. But then kernel
developers chicken out and dump this problem onto users, which happily
enable all kinds of options they hear about. And then when it eats
their data or crashes machines everyone shrugs and says "oh well you
probably have one of the broken machines, don't enable this" and moves
on.

There's certainly the case that some tuning stuff in core kernel has
real downsides to either perf or power, but generally (for device
drivers) I feel like simply not enabling the all the power features is
a cheap way to chicken out of bugs reports and responsibility. I'm
somewhat opionated on this ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Rafael J. Wysocki]

On Tuesday, July 14, 2015 06:51:31 PM Daniel Vetter wrote:
> On Tue, Jul 14, 2015 at 1:07 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > However, there are places in the kernel where there is a real tradeoff between
> > power and performance (or power and capacity in general) and there are places
> > that tend to keep conservative settings for fear of exposing latent bugs to
> > a wide community of users.
> >
> > Those might benefit from allowing the users to relax the settings globally
> > if they want to.
> 
> Well that's the approach I don't like personally. Essentially we
> should be the experts on what works and what doesn't. But then kernel
> developers chicken out and dump this problem onto users, which happily
> enable all kinds of options they hear about. And then when it eats
> their data or crashes machines everyone shrugs and says "oh well you
> probably have one of the broken machines, don't enable this" and moves
> on.
> 
> There's certainly the case that some tuning stuff in core kernel has
> real downsides to either perf or power, but generally (for device
> drivers) I feel like simply not enabling the all the power features is
> a cheap way to chicken out of bugs reports and responsibility. I'm
> somewhat opionated on this ;-)

But that's what's happening.  Many PM features are not enabled by default for
this reason or another.

The point here is whether or not we want to have a way to make all of them be
enabled by default instead and see what happens, for example.

Thanks,
Rafael

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

[Josh Triplett]

On Thu, Jul 16, 2015 at 12:44:01AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 14, 2015 06:51:31 PM Daniel Vetter wrote:
> > On Tue, Jul 14, 2015 at 1:07 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > However, there are places in the kernel where there is a real tradeoff between
> > > power and performance (or power and capacity in general) and there are places
> > > that tend to keep conservative settings for fear of exposing latent bugs to
> > > a wide community of users.
> > >
> > > Those might benefit from allowing the users to relax the settings globally
> > > if they want to.
> > 
> > Well that's the approach I don't like personally. Essentially we
> > should be the experts on what works and what doesn't. But then kernel
> > developers chicken out and dump this problem onto users, which happily
> > enable all kinds of options they hear about. And then when it eats
> > their data or crashes machines everyone shrugs and says "oh well you
> > probably have one of the broken machines, don't enable this" and moves
> > on.
> > 
> > There's certainly the case that some tuning stuff in core kernel has
> > real downsides to either perf or power, but generally (for device
> > drivers) I feel like simply not enabling the all the power features is
> > a cheap way to chicken out of bugs reports and responsibility. I'm
> > somewhat opionated on this ;-)
> 
> But that's what's happening.  Many PM features are not enabled by default for
> this reason or another.
> 
> The point here is whether or not we want to have a way to make all of them be
> enabled by default instead and see what happens, for example.

To some degree that seems like an admission of defeat: we can't possibly
do the right thing by default, so we give up and add a way for the user
to configure it.

We should be selecting the most sensible combination of power and
performance by default; we should not punt that question to the average
user, *or* to the distros.

- Josh Triplett

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

[David Woodhouse]

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

On Wed, 2015-07-15 at 18:10 -0700, Josh Triplett wrote:
> 
> > The point here is whether or not we want to have a way to make all of them be
> > enabled by default instead and see what happens, for example.
> 
> To some degree that seems like an admission of defeat: we can't possibly
> do the right thing by default, so we give up and add a way for the user
> to configure it.
>
> We should be selecting the most sensible combination of power and
> performance by default; we should not punt that question to the average
> user, *or* to the distros.

Not to the user, perhaps. But it's not *so* unreasonable to let each of
the distros tune things for *their* class of users. We might want base
profiles for 'server', 'desktop' and 'laptop on battery' that distros
work from.

But although that's complex, it's not the real problem.

The real problem, as others have said, is when we have power management
features which work fine for 99% of the population, but fail
occasionally on broken hardware.

We can't easily blacklist the known-broken devices or whitelist the
good ones, and we end up having to turn the feature off by default.

Sure, a DMI match on "HP" and "TO BE FILLED BY OEM" would often go a
long way for a certain class of problem, but even that's not sufficient
:)

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

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

[Kristen Accardi]

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

On Thu, Jul 16, 2015 at 2:19 AM David Woodhouse <dwmw2@infradead.org> wrote:

> On Wed, 2015-07-15 at 18:10 -0700, Josh Triplett wrote:
> >
> > > The point here is whether or not we want to have a way to make all of
> them be
> > > enabled by default instead and see what happens, for example.
> >
> > To some degree that seems like an admission of defeat: we can't possibly
> > do the right thing by default, so we give up and add a way for the user
> > to configure it.
> >
> > We should be selecting the most sensible combination of power and
> > performance by default; we should not punt that question to the average
> > user, *or* to the distros.
>
> Not to the user, perhaps. But it's not *so* unreasonable to let each of
> the distros tune things for *their* class of users. We might want base
> profiles for 'server', 'desktop' and 'laptop on battery' that distros
> work from.
>
>
We need to be able to give even the distros more help than they have now.
The problem is that the distros simply don't have the knowledge to tune
*all* the knobs appropriately.  If we gave them one knob as you suggested
(and what Rafael is suggesting) set to a sane default determined by the
kernel - they could then use whatever userspace tool to change it based on
whatever parameters they want.

But although that's complex, it's not the real problem.
>
> The real problem, as others have said, is when we have power management
> features which work fine for 99% of the population, but fail
> occasionally on broken hardware.
>
> We can't easily blacklist the known-broken devices or whitelist the
> good ones, and we end up having to turn the feature off by default.
>
> Sure, a DMI match on "HP" and "TO BE FILLED BY OEM" would often go a
> long way for a certain class of problem, but even that's not sufficient
> :)
>

driver maintainers don't want to maintain blacklist/whitelist because it's
hard.  It'd be nice to be able to load a black list or white list of
devices from the filesystem like we do with firmware.

>
>

[-- Attachment #2: Type: text/html, Size: 2769 bytes --]

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

[Josh Triplett]

On Thu, Jul 16, 2015 at 03:44:57PM +0000, Kristen Accardi wrote:
> On Thu, Jul 16, 2015 at 2:19 AM David Woodhouse <dwmw2@infradead.org> wrote:
> 
> > On Wed, 2015-07-15 at 18:10 -0700, Josh Triplett wrote:
> > >
> > > > The point here is whether or not we want to have a way to make all of
> > them be
> > > > enabled by default instead and see what happens, for example.
> > >
> > > To some degree that seems like an admission of defeat: we can't possibly
> > > do the right thing by default, so we give up and add a way for the user
> > > to configure it.
> > >
> > > We should be selecting the most sensible combination of power and
> > > performance by default; we should not punt that question to the average
> > > user, *or* to the distros.
> >
> > Not to the user, perhaps. But it's not *so* unreasonable to let each of
> > the distros tune things for *their* class of users. We might want base
> > profiles for 'server', 'desktop' and 'laptop on battery' that distros
> > work from.
> >
> >
> We need to be able to give even the distros more help than they have now.
> The problem is that the distros simply don't have the knowledge to tune
> *all* the knobs appropriately.  If we gave them one knob as you suggested
> (and what Rafael is suggesting) set to a sane default determined by the
> kernel - they could then use whatever userspace tool to change it based on
> whatever parameters they want.

Even if there's a single knob, that *still* doesn't let us turn on power
management features that break with certain devices.

> But although that's complex, it's not the real problem.
> >
> > The real problem, as others have said, is when we have power management
> > features which work fine for 99% of the population, but fail
> > occasionally on broken hardware.
> >
> > We can't easily blacklist the known-broken devices or whitelist the
> > good ones, and we end up having to turn the feature off by default.
> >
> > Sure, a DMI match on "HP" and "TO BE FILLED BY OEM" would often go a
> > long way for a certain class of problem, but even that's not sufficient
> > :)
> >
> 
> driver maintainers don't want to maintain blacklist/whitelist because it's
> hard.  It'd be nice to be able to load a black list or white list of
> devices from the filesystem like we do with firmware.

If the devices are identifiable from userspace, udev or similar could
set these settings from a rules file.

But the kernel already has quirk tables for various hardware, and that
seems appropriate to continue putting in the kernel.

- Josh Triplett

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

[Greg KH]

On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> But the kernel already has quirk tables for various hardware, and that
> seems appropriate to continue putting in the kernel.

For some types of devices, sure.  For others, like broken USB keyboards
that can't handle autosuspend, no.  For those we need a userspace
_whitelist_ that udev can use.  So there's no one answer that works for
all types of quirks.

thanks,

greg k-h

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

[Takashi Iwai]

On Thu, 16 Jul 2015 17:58:19 +0200,
Greg KH wrote:
> 
> On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> > But the kernel already has quirk tables for various hardware, and that
> > seems appropriate to continue putting in the kernel.
> 
> For some types of devices, sure.  For others, like broken USB keyboards
> that can't handle autosuspend, no.  For those we need a userspace
> _whitelist_ that udev can use.  So there's no one answer that works for
> all types of quirks.

That's my concern, too.  If we give a single knob for all components,
most likely some components shall be broken.  And I'm sure that many of
the breakage will be left unfixed due to all reasons you can imagine.


Takashi

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

[Daniel Vetter]

On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
>> But the kernel already has quirk tables for various hardware, and that
>> seems appropriate to continue putting in the kernel.
>
> For some types of devices, sure.  For others, like broken USB keyboards
> that can't handle autosuspend, no.  For those we need a userspace
> _whitelist_ that udev can use.  So there's no one answer that works for
> all types of quirks.

Whether white or blacklist or some other mixed thing doesn't really
matter. Imo the important part is that driver maintainers are in the
best position to maintain that, and pushing it out to anyone else is
just really not doing our jobs. And I think for most of these quirk
lists the kernel does seem like the most appropriate place. If the
list becomes giantic then we can move it to userspace (if that's
really a problem, afaik no one proposed yet to move device match
tables into userspace either and that's kinda the same thing really).
But as long as there's no white/black/whatever list yet starting in
the kernel is imo the right place.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Rafael J. Wysocki]

On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> >> But the kernel already has quirk tables for various hardware, and that
> >> seems appropriate to continue putting in the kernel.
> >
> > For some types of devices, sure.  For others, like broken USB keyboards
> > that can't handle autosuspend, no.  For those we need a userspace
> > _whitelist_ that udev can use.  So there's no one answer that works for
> > all types of quirks.
> 
> Whether white or blacklist or some other mixed thing doesn't really
> matter. Imo the important part is that driver maintainers are in the
> best position to maintain that, and pushing it out to anyone else is
> just really not doing our jobs. And I think for most of these quirk
> lists the kernel does seem like the most appropriate place. If the
> list becomes giantic then we can move it to userspace (if that's
> really a problem, afaik no one proposed yet to move device match
> tables into userspace either and that's kinda the same thing really).
> But as long as there's no white/black/whatever list yet starting in
> the kernel is imo the right place.

Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
for one example?

Failing to enable it prevents some SoCs from using the deepest available
C-states which in turn hurts battery life of the systems containing them
quite a bit, so there surely is a reason to have it enabled.

Thanks,
Rafael

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

[Daniel Vetter]

On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
>> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
>> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
>> >> But the kernel already has quirk tables for various hardware, and that
>> >> seems appropriate to continue putting in the kernel.
>> >
>> > For some types of devices, sure.  For others, like broken USB keyboards
>> > that can't handle autosuspend, no.  For those we need a userspace
>> > _whitelist_ that udev can use.  So there's no one answer that works for
>> > all types of quirks.
>>
>> Whether white or blacklist or some other mixed thing doesn't really
>> matter. Imo the important part is that driver maintainers are in the
>> best position to maintain that, and pushing it out to anyone else is
>> just really not doing our jobs. And I think for most of these quirk
>> lists the kernel does seem like the most appropriate place. If the
>> list becomes giantic then we can move it to userspace (if that's
>> really a problem, afaik no one proposed yet to move device match
>> tables into userspace either and that's kinda the same thing really).
>> But as long as there's no white/black/whatever list yet starting in
>> the kernel is imo the right place.
>
> Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
> for one example?
>
> Failing to enable it prevents some SoCs from using the deepest available
> C-states which in turn hurts battery life of the systems containing them
> quite a bit, so there surely is a reason to have it enabled.

Because it's broken on a lot of machines, and it takes a pile of
effort to fix it. That work is under way now, but for a long time
priorities set by management where much more set on chasing the next
shiny thing. Took a few years of making noises about dropping it all
if it doesn't get fixed.

This is actually a perfect example of what I mean with "hey it works
on my machine here, but I can't be bothered to fix up the corner-cases
so let's keep it disabled and move on". And the corner cases are hung
machines and frozen displays (and a few other things), and we
inflicted that a few times on Linus even.

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

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

[Rafael J. Wysocki]

On Tuesday, July 21, 2015 01:09:52 AM Daniel Vetter wrote:
> On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
> >> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> >> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> >> >> But the kernel already has quirk tables for various hardware, and that
> >> >> seems appropriate to continue putting in the kernel.
> >> >
> >> > For some types of devices, sure.  For others, like broken USB keyboards
> >> > that can't handle autosuspend, no.  For those we need a userspace
> >> > _whitelist_ that udev can use.  So there's no one answer that works for
> >> > all types of quirks.
> >>
> >> Whether white or blacklist or some other mixed thing doesn't really
> >> matter. Imo the important part is that driver maintainers are in the
> >> best position to maintain that, and pushing it out to anyone else is
> >> just really not doing our jobs. And I think for most of these quirk
> >> lists the kernel does seem like the most appropriate place. If the
> >> list becomes giantic then we can move it to userspace (if that's
> >> really a problem, afaik no one proposed yet to move device match
> >> tables into userspace either and that's kinda the same thing really).
> >> But as long as there's no white/black/whatever list yet starting in
> >> the kernel is imo the right place.
> >
> > Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
> > for one example?
> >
> > Failing to enable it prevents some SoCs from using the deepest available
> > C-states which in turn hurts battery life of the systems containing them
> > quite a bit, so there surely is a reason to have it enabled.
> 
> Because it's broken on a lot of machines, and it takes a pile of
> effort to fix it.

And there are quite a few subsystems having similar issues here and there.

People who aren't aware of those command line/Kconfig/sysfs switches will
never enable those features even though they may work well on their
machines and may actually be necessary to save energy.

> That work is under way now, but for a long time
> priorities set by management where much more set on chasing the next
> shiny thing. Took a few years of making noises about dropping it all
> if it doesn't get fixed.
> 
> This is actually a perfect example of what I mean with "hey it works
> on my machine here, but I can't be bothered to fix up the corner-cases
> so let's keep it disabled and move on". And the corner cases are hung
> machines and frozen displays (and a few other things), and we
> inflicted that a few times on Linus even.

So among other things this topic is about a mechanism to possibly enable
multiple things like that in one go instead of having to switch multiple
knobs in various places (and needing to know about them in the first
place).

Thanks,
Rafael

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

[Daniel Vetter]

On Wed, Jul 22, 2015 at 3:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, July 21, 2015 01:09:52 AM Daniel Vetter wrote:
>> On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
>> >> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
>> >> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
>> >> >> But the kernel already has quirk tables for various hardware, and that
>> >> >> seems appropriate to continue putting in the kernel.
>> >> >
>> >> > For some types of devices, sure.  For others, like broken USB keyboards
>> >> > that can't handle autosuspend, no.  For those we need a userspace
>> >> > _whitelist_ that udev can use.  So there's no one answer that works for
>> >> > all types of quirks.
>> >>
>> >> Whether white or blacklist or some other mixed thing doesn't really
>> >> matter. Imo the important part is that driver maintainers are in the
>> >> best position to maintain that, and pushing it out to anyone else is
>> >> just really not doing our jobs. And I think for most of these quirk
>> >> lists the kernel does seem like the most appropriate place. If the
>> >> list becomes giantic then we can move it to userspace (if that's
>> >> really a problem, afaik no one proposed yet to move device match
>> >> tables into userspace either and that's kinda the same thing really).
>> >> But as long as there's no white/black/whatever list yet starting in
>> >> the kernel is imo the right place.
>> >
>> > Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
>> > for one example?
>> >
>> > Failing to enable it prevents some SoCs from using the deepest available
>> > C-states which in turn hurts battery life of the systems containing them
>> > quite a bit, so there surely is a reason to have it enabled.
>>
>> Because it's broken on a lot of machines, and it takes a pile of
>> effort to fix it.
>
> And there are quite a few subsystems having similar issues here and there.
>
> People who aren't aware of those command line/Kconfig/sysfs switches will
> never enable those features even though they may work well on their
> machines and may actually be necessary to save energy.

In my experience there's way too many people around who know about
these knobs but have no idea that they might be somewhat dangerous.
And then I get another bug report about a known bug just because
someone read a blog somewhere. Nowadays almost all i915 tuning knobs
are marked as _unsafe and taint your kernel if you touch them.

>> That work is under way now, but for a long time
>> priorities set by management where much more set on chasing the next
>> shiny thing. Took a few years of making noises about dropping it all
>> if it doesn't get fixed.
>>
>> This is actually a perfect example of what I mean with "hey it works
>> on my machine here, but I can't be bothered to fix up the corner-cases
>> so let's keep it disabled and move on". And the corner cases are hung
>> machines and frozen displays (and a few other things), and we
>> inflicted that a few times on Linus even.
>
> So among other things this topic is about a mechanism to possibly enable
> multiple things like that in one go instead of having to switch multiple
> knobs in various places (and needing to know about them in the first
> place).

I know, but at least for i915 I don't want it: When we know it's safe
to do we already enable all the power/performance tuning we have, and
if we know it's unsafe we don't want users to enable it themselves. If
you have a very specific product (which is not a generic distro or
anything) and have done careful testing and cross-checked with
developers then you can of course just enable these features. But then
you also don't need a new option, you can just change the driver
defaults directly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Rafael J. Wysocki]

On Wednesday, July 22, 2015 09:18:34 AM Daniel Vetter wrote:
> On Wed, Jul 22, 2015 at 3:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, July 21, 2015 01:09:52 AM Daniel Vetter wrote:
> >> On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
> >> >> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> >> >> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> >> >> >> But the kernel already has quirk tables for various hardware, and that
> >> >> >> seems appropriate to continue putting in the kernel.
> >> >> >
> >> >> > For some types of devices, sure.  For others, like broken USB keyboards
> >> >> > that can't handle autosuspend, no.  For those we need a userspace
> >> >> > _whitelist_ that udev can use.  So there's no one answer that works for
> >> >> > all types of quirks.
> >> >>
> >> >> Whether white or blacklist or some other mixed thing doesn't really
> >> >> matter. Imo the important part is that driver maintainers are in the
> >> >> best position to maintain that, and pushing it out to anyone else is
> >> >> just really not doing our jobs. And I think for most of these quirk
> >> >> lists the kernel does seem like the most appropriate place. If the
> >> >> list becomes giantic then we can move it to userspace (if that's
> >> >> really a problem, afaik no one proposed yet to move device match
> >> >> tables into userspace either and that's kinda the same thing really).
> >> >> But as long as there's no white/black/whatever list yet starting in
> >> >> the kernel is imo the right place.
> >> >
> >> > Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
> >> > for one example?
> >> >
> >> > Failing to enable it prevents some SoCs from using the deepest available
> >> > C-states which in turn hurts battery life of the systems containing them
> >> > quite a bit, so there surely is a reason to have it enabled.
> >>
> >> Because it's broken on a lot of machines, and it takes a pile of
> >> effort to fix it.
> >
> > And there are quite a few subsystems having similar issues here and there.
> >
> > People who aren't aware of those command line/Kconfig/sysfs switches will
> > never enable those features even though they may work well on their
> > machines and may actually be necessary to save energy.
> 
> In my experience there's way too many people around who know about
> these knobs but have no idea that they might be somewhat dangerous.
> And then I get another bug report about a known bug just because
> someone read a blog somewhere. Nowadays almost all i915 tuning knobs
> are marked as _unsafe and taint your kernel if you touch them.
> 
> >> That work is under way now, but for a long time
> >> priorities set by management where much more set on chasing the next
> >> shiny thing. Took a few years of making noises about dropping it all
> >> if it doesn't get fixed.
> >>
> >> This is actually a perfect example of what I mean with "hey it works
> >> on my machine here, but I can't be bothered to fix up the corner-cases
> >> so let's keep it disabled and move on". And the corner cases are hung
> >> machines and frozen displays (and a few other things), and we
> >> inflicted that a few times on Linus even.
> >
> > So among other things this topic is about a mechanism to possibly enable
> > multiple things like that in one go instead of having to switch multiple
> > knobs in various places (and needing to know about them in the first
> > place).
> 
> I know, but at least for i915 I don't want it: When we know it's safe
> to do we already enable all the power/performance tuning we have, and
> if we know it's unsafe we don't want users to enable it themselves. If
> you have a very specific product (which is not a generic distro or
> anything) and have done careful testing and cross-checked with
> developers then you can of course just enable these features. But then
> you also don't need a new option, you can just change the driver
> defaults directly.

OK

So perhaps the question should be whether or not there is any viable approach
we can use to avoid or at least reduce the amount of all of the mostly manual
tuning to get as much battery life from systems as they can provide.  And that
cannot involve user space realistically, because some variants of it may just
not do whatever we expect them to do.

Thanks,
Rafael

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

[josh]

On Wed, Jul 22, 2015 at 07:25:40PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 22, 2015 09:18:34 AM Daniel Vetter wrote:
> > On Wed, Jul 22, 2015 at 3:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > On Tuesday, July 21, 2015 01:09:52 AM Daniel Vetter wrote:
> > >> On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > >> > On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
> > >> >> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> > >> >> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> > >> >> >> But the kernel already has quirk tables for various hardware, and that
> > >> >> >> seems appropriate to continue putting in the kernel.
> > >> >> >
> > >> >> > For some types of devices, sure.  For others, like broken USB keyboards
> > >> >> > that can't handle autosuspend, no.  For those we need a userspace
> > >> >> > _whitelist_ that udev can use.  So there's no one answer that works for
> > >> >> > all types of quirks.
> > >> >>
> > >> >> Whether white or blacklist or some other mixed thing doesn't really
> > >> >> matter. Imo the important part is that driver maintainers are in the
> > >> >> best position to maintain that, and pushing it out to anyone else is
> > >> >> just really not doing our jobs. And I think for most of these quirk
> > >> >> lists the kernel does seem like the most appropriate place. If the
> > >> >> list becomes giantic then we can move it to userspace (if that's
> > >> >> really a problem, afaik no one proposed yet to move device match
> > >> >> tables into userspace either and that's kinda the same thing really).
> > >> >> But as long as there's no white/black/whatever list yet starting in
> > >> >> the kernel is imo the right place.
> > >> >
> > >> > Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
> > >> > for one example?
> > >> >
> > >> > Failing to enable it prevents some SoCs from using the deepest available
> > >> > C-states which in turn hurts battery life of the systems containing them
> > >> > quite a bit, so there surely is a reason to have it enabled.
> > >>
> > >> Because it's broken on a lot of machines, and it takes a pile of
> > >> effort to fix it.
> > >
> > > And there are quite a few subsystems having similar issues here and there.
> > >
> > > People who aren't aware of those command line/Kconfig/sysfs switches will
> > > never enable those features even though they may work well on their
> > > machines and may actually be necessary to save energy.
> > 
> > In my experience there's way too many people around who know about
> > these knobs but have no idea that they might be somewhat dangerous.
> > And then I get another bug report about a known bug just because
> > someone read a blog somewhere. Nowadays almost all i915 tuning knobs
> > are marked as _unsafe and taint your kernel if you touch them.
> > 
> > >> That work is under way now, but for a long time
> > >> priorities set by management where much more set on chasing the next
> > >> shiny thing. Took a few years of making noises about dropping it all
> > >> if it doesn't get fixed.
> > >>
> > >> This is actually a perfect example of what I mean with "hey it works
> > >> on my machine here, but I can't be bothered to fix up the corner-cases
> > >> so let's keep it disabled and move on". And the corner cases are hung
> > >> machines and frozen displays (and a few other things), and we
> > >> inflicted that a few times on Linus even.
> > >
> > > So among other things this topic is about a mechanism to possibly enable
> > > multiple things like that in one go instead of having to switch multiple
> > > knobs in various places (and needing to know about them in the first
> > > place).
> > 
> > I know, but at least for i915 I don't want it: When we know it's safe
> > to do we already enable all the power/performance tuning we have, and
> > if we know it's unsafe we don't want users to enable it themselves. If
> > you have a very specific product (which is not a generic distro or
> > anything) and have done careful testing and cross-checked with
> > developers then you can of course just enable these features. But then
> > you also don't need a new option, you can just change the driver
> > defaults directly.
> 
> OK
> 
> So perhaps the question should be whether or not there is any viable approach
> we can use to avoid or at least reduce the amount of all of the mostly manual
> tuning to get as much battery life from systems as they can provide.  And that
> cannot involve user space realistically, because some variants of it may just
> not do whatever we expect them to do.

Tunables like those in i915 aren't going to be able to use any better
approach, specifically because they don't work everywhere; if we had a
list of systems they were safe on, we'd set up a quirk list and turn
them on by default.  Do we have any tunables that *aren't* in that
category?  And if so, why don't we just set their defaults to DTRT?

- Josh Triplett

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

[Rafael J. Wysocki]

On Wednesday, July 22, 2015 11:25:19 AM josh@joshtriplett.org wrote:
> On Wed, Jul 22, 2015 at 07:25:40PM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, July 22, 2015 09:18:34 AM Daniel Vetter wrote:
> > > On Wed, Jul 22, 2015 at 3:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > On Tuesday, July 21, 2015 01:09:52 AM Daniel Vetter wrote:
> > > >> On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > >> > On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
> > > >> >> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> > > >> >> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> > > >> >> >> But the kernel already has quirk tables for various hardware, and that
> > > >> >> >> seems appropriate to continue putting in the kernel.
> > > >> >> >
> > > >> >> > For some types of devices, sure.  For others, like broken USB keyboards
> > > >> >> > that can't handle autosuspend, no.  For those we need a userspace
> > > >> >> > _whitelist_ that udev can use.  So there's no one answer that works for
> > > >> >> > all types of quirks.
> > > >> >>
> > > >> >> Whether white or blacklist or some other mixed thing doesn't really
> > > >> >> matter. Imo the important part is that driver maintainers are in the
> > > >> >> best position to maintain that, and pushing it out to anyone else is
> > > >> >> just really not doing our jobs. And I think for most of these quirk
> > > >> >> lists the kernel does seem like the most appropriate place. If the
> > > >> >> list becomes giantic then we can move it to userspace (if that's
> > > >> >> really a problem, afaik no one proposed yet to move device match
> > > >> >> tables into userspace either and that's kinda the same thing really).
> > > >> >> But as long as there's no white/black/whatever list yet starting in
> > > >> >> the kernel is imo the right place.
> > > >> >
> > > >> > Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
> > > >> > for one example?
> > > >> >
> > > >> > Failing to enable it prevents some SoCs from using the deepest available
> > > >> > C-states which in turn hurts battery life of the systems containing them
> > > >> > quite a bit, so there surely is a reason to have it enabled.
> > > >>
> > > >> Because it's broken on a lot of machines, and it takes a pile of
> > > >> effort to fix it.
> > > >
> > > > And there are quite a few subsystems having similar issues here and there.
> > > >
> > > > People who aren't aware of those command line/Kconfig/sysfs switches will
> > > > never enable those features even though they may work well on their
> > > > machines and may actually be necessary to save energy.
> > > 
> > > In my experience there's way too many people around who know about
> > > these knobs but have no idea that they might be somewhat dangerous.
> > > And then I get another bug report about a known bug just because
> > > someone read a blog somewhere. Nowadays almost all i915 tuning knobs
> > > are marked as _unsafe and taint your kernel if you touch them.
> > > 
> > > >> That work is under way now, but for a long time
> > > >> priorities set by management where much more set on chasing the next
> > > >> shiny thing. Took a few years of making noises about dropping it all
> > > >> if it doesn't get fixed.
> > > >>
> > > >> This is actually a perfect example of what I mean with "hey it works
> > > >> on my machine here, but I can't be bothered to fix up the corner-cases
> > > >> so let's keep it disabled and move on". And the corner cases are hung
> > > >> machines and frozen displays (and a few other things), and we
> > > >> inflicted that a few times on Linus even.
> > > >
> > > > So among other things this topic is about a mechanism to possibly enable
> > > > multiple things like that in one go instead of having to switch multiple
> > > > knobs in various places (and needing to know about them in the first
> > > > place).
> > > 
> > > I know, but at least for i915 I don't want it: When we know it's safe
> > > to do we already enable all the power/performance tuning we have, and
> > > if we know it's unsafe we don't want users to enable it themselves. If
> > > you have a very specific product (which is not a generic distro or
> > > anything) and have done careful testing and cross-checked with
> > > developers then you can of course just enable these features. But then
> > > you also don't need a new option, you can just change the driver
> > > defaults directly.
> > 
> > OK
> > 
> > So perhaps the question should be whether or not there is any viable approach
> > we can use to avoid or at least reduce the amount of all of the mostly manual
> > tuning to get as much battery life from systems as they can provide.  And that
> > cannot involve user space realistically, because some variants of it may just
> > not do whatever we expect them to do.
> 
> Tunables like those in i915 aren't going to be able to use any better
> approach, specifically because they don't work everywhere; if we had a
> list of systems they were safe on, we'd set up a quirk list and turn
> them on by default.  Do we have any tunables that *aren't* in that
> category?

I really don't think so, maybe except for some corner things.

> And if so, why don't we just set their defaults to DTRT?

But we seem to have more and more tunables for things that "don't work
everywhere", while at the same time the subset of systems where they *do* work
is quite substantial.

In many cases we simply don't have enough information to create a black or white
list for them, so we disable them by default and add a tunable to enable them
"in case someone needs" them.  This bothers me a bit, because it doesn't seem
to be sustainable in the long term.

Thanks,
Rafael

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

[Josh Triplett]

On Sat, Jul 25, 2015 at 12:36:18AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 22, 2015 11:25:19 AM josh@joshtriplett.org wrote:
> > On Wed, Jul 22, 2015 at 07:25:40PM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, July 22, 2015 09:18:34 AM Daniel Vetter wrote:
> > > > On Wed, Jul 22, 2015 at 3:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > > On Tuesday, July 21, 2015 01:09:52 AM Daniel Vetter wrote:
> > > > >> On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > >> > On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
> > > > >> >> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> > > > >> >> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> > > > >> >> >> But the kernel already has quirk tables for various hardware, and that
> > > > >> >> >> seems appropriate to continue putting in the kernel.
> > > > >> >> >
> > > > >> >> > For some types of devices, sure.  For others, like broken USB keyboards
> > > > >> >> > that can't handle autosuspend, no.  For those we need a userspace
> > > > >> >> > _whitelist_ that udev can use.  So there's no one answer that works for
> > > > >> >> > all types of quirks.
> > > > >> >>
> > > > >> >> Whether white or blacklist or some other mixed thing doesn't really
> > > > >> >> matter. Imo the important part is that driver maintainers are in the
> > > > >> >> best position to maintain that, and pushing it out to anyone else is
> > > > >> >> just really not doing our jobs. And I think for most of these quirk
> > > > >> >> lists the kernel does seem like the most appropriate place. If the
> > > > >> >> list becomes giantic then we can move it to userspace (if that's
> > > > >> >> really a problem, afaik no one proposed yet to move device match
> > > > >> >> tables into userspace either and that's kinda the same thing really).
> > > > >> >> But as long as there's no white/black/whatever list yet starting in
> > > > >> >> the kernel is imo the right place.
> > > > >> >
> > > > >> > Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
> > > > >> > for one example?
> > > > >> >
> > > > >> > Failing to enable it prevents some SoCs from using the deepest available
> > > > >> > C-states which in turn hurts battery life of the systems containing them
> > > > >> > quite a bit, so there surely is a reason to have it enabled.
> > > > >>
> > > > >> Because it's broken on a lot of machines, and it takes a pile of
> > > > >> effort to fix it.
> > > > >
> > > > > And there are quite a few subsystems having similar issues here and there.
> > > > >
> > > > > People who aren't aware of those command line/Kconfig/sysfs switches will
> > > > > never enable those features even though they may work well on their
> > > > > machines and may actually be necessary to save energy.
> > > > 
> > > > In my experience there's way too many people around who know about
> > > > these knobs but have no idea that they might be somewhat dangerous.
> > > > And then I get another bug report about a known bug just because
> > > > someone read a blog somewhere. Nowadays almost all i915 tuning knobs
> > > > are marked as _unsafe and taint your kernel if you touch them.
> > > > 
> > > > >> That work is under way now, but for a long time
> > > > >> priorities set by management where much more set on chasing the next
> > > > >> shiny thing. Took a few years of making noises about dropping it all
> > > > >> if it doesn't get fixed.
> > > > >>
> > > > >> This is actually a perfect example of what I mean with "hey it works
> > > > >> on my machine here, but I can't be bothered to fix up the corner-cases
> > > > >> so let's keep it disabled and move on". And the corner cases are hung
> > > > >> machines and frozen displays (and a few other things), and we
> > > > >> inflicted that a few times on Linus even.
> > > > >
> > > > > So among other things this topic is about a mechanism to possibly enable
> > > > > multiple things like that in one go instead of having to switch multiple
> > > > > knobs in various places (and needing to know about them in the first
> > > > > place).
> > > > 
> > > > I know, but at least for i915 I don't want it: When we know it's safe
> > > > to do we already enable all the power/performance tuning we have, and
> > > > if we know it's unsafe we don't want users to enable it themselves. If
> > > > you have a very specific product (which is not a generic distro or
> > > > anything) and have done careful testing and cross-checked with
> > > > developers then you can of course just enable these features. But then
> > > > you also don't need a new option, you can just change the driver
> > > > defaults directly.
> > > 
> > > OK
> > > 
> > > So perhaps the question should be whether or not there is any viable approach
> > > we can use to avoid or at least reduce the amount of all of the mostly manual
> > > tuning to get as much battery life from systems as they can provide.  And that
> > > cannot involve user space realistically, because some variants of it may just
> > > not do whatever we expect them to do.
> > 
> > Tunables like those in i915 aren't going to be able to use any better
> > approach, specifically because they don't work everywhere; if we had a
> > list of systems they were safe on, we'd set up a quirk list and turn
> > them on by default.  Do we have any tunables that *aren't* in that
> > category?
> 
> I really don't think so, maybe except for some corner things.
> 
> > And if so, why don't we just set their defaults to DTRT?
> 
> But we seem to have more and more tunables for things that "don't work
> everywhere", while at the same time the subset of systems where they *do* work
> is quite substantial.
> 
> In many cases we simply don't have enough information to create a black or white
> list for them, so we disable them by default and add a tunable to enable them
> "in case someone needs" them.  This bothers me a bit, because it doesn't seem
> to be sustainable in the long term.

I agree completely.

However, it seems like there's always enough information for a
whitelist, if you know at least one system it works on.  Then people can
submit patches extending the whitelist.

But in any case, this seems to argue against a global "use less power"
switch, because any one of the underlying options might potentially
break on the user's system.  Any that can be safely toggled by a master
switch should just come pre-toggled. :)

- Josh Triplett

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

[Rafael J. Wysocki]

On Saturday, July 25, 2015 12:50:16 PM Josh Triplett wrote:
> On Sat, Jul 25, 2015 at 12:36:18AM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, July 22, 2015 11:25:19 AM josh@joshtriplett.org wrote:
> > > On Wed, Jul 22, 2015 at 07:25:40PM +0200, Rafael J. Wysocki wrote:
> > > > On Wednesday, July 22, 2015 09:18:34 AM Daniel Vetter wrote:
> > > > > On Wed, Jul 22, 2015 at 3:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > > > On Tuesday, July 21, 2015 01:09:52 AM Daniel Vetter wrote:
> > > > > >> On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > > >> > On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
> > > > > >> >> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> > > > > >> >> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> > > > > >> >> >> But the kernel already has quirk tables for various hardware, and that
> > > > > >> >> >> seems appropriate to continue putting in the kernel.
> > > > > >> >> >
> > > > > >> >> > For some types of devices, sure.  For others, like broken USB keyboards
> > > > > >> >> > that can't handle autosuspend, no.  For those we need a userspace
> > > > > >> >> > _whitelist_ that udev can use.  So there's no one answer that works for
> > > > > >> >> > all types of quirks.
> > > > > >> >>
> > > > > >> >> Whether white or blacklist or some other mixed thing doesn't really
> > > > > >> >> matter. Imo the important part is that driver maintainers are in the
> > > > > >> >> best position to maintain that, and pushing it out to anyone else is
> > > > > >> >> just really not doing our jobs. And I think for most of these quirk
> > > > > >> >> lists the kernel does seem like the most appropriate place. If the
> > > > > >> >> list becomes giantic then we can move it to userspace (if that's
> > > > > >> >> really a problem, afaik no one proposed yet to move device match
> > > > > >> >> tables into userspace either and that's kinda the same thing really).
> > > > > >> >> But as long as there's no white/black/whatever list yet starting in
> > > > > >> >> the kernel is imo the right place.
> > > > > >> >
> > > > > >> > Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
> > > > > >> > for one example?
> > > > > >> >
> > > > > >> > Failing to enable it prevents some SoCs from using the deepest available
> > > > > >> > C-states which in turn hurts battery life of the systems containing them
> > > > > >> > quite a bit, so there surely is a reason to have it enabled.
> > > > > >>
> > > > > >> Because it's broken on a lot of machines, and it takes a pile of
> > > > > >> effort to fix it.
> > > > > >
> > > > > > And there are quite a few subsystems having similar issues here and there.
> > > > > >
> > > > > > People who aren't aware of those command line/Kconfig/sysfs switches will
> > > > > > never enable those features even though they may work well on their
> > > > > > machines and may actually be necessary to save energy.
> > > > > 
> > > > > In my experience there's way too many people around who know about
> > > > > these knobs but have no idea that they might be somewhat dangerous.
> > > > > And then I get another bug report about a known bug just because
> > > > > someone read a blog somewhere. Nowadays almost all i915 tuning knobs
> > > > > are marked as _unsafe and taint your kernel if you touch them.
> > > > > 
> > > > > >> That work is under way now, but for a long time
> > > > > >> priorities set by management where much more set on chasing the next
> > > > > >> shiny thing. Took a few years of making noises about dropping it all
> > > > > >> if it doesn't get fixed.
> > > > > >>
> > > > > >> This is actually a perfect example of what I mean with "hey it works
> > > > > >> on my machine here, but I can't be bothered to fix up the corner-cases
> > > > > >> so let's keep it disabled and move on". And the corner cases are hung
> > > > > >> machines and frozen displays (and a few other things), and we
> > > > > >> inflicted that a few times on Linus even.
> > > > > >
> > > > > > So among other things this topic is about a mechanism to possibly enable
> > > > > > multiple things like that in one go instead of having to switch multiple
> > > > > > knobs in various places (and needing to know about them in the first
> > > > > > place).
> > > > > 
> > > > > I know, but at least for i915 I don't want it: When we know it's safe
> > > > > to do we already enable all the power/performance tuning we have, and
> > > > > if we know it's unsafe we don't want users to enable it themselves. If
> > > > > you have a very specific product (which is not a generic distro or
> > > > > anything) and have done careful testing and cross-checked with
> > > > > developers then you can of course just enable these features. But then
> > > > > you also don't need a new option, you can just change the driver
> > > > > defaults directly.
> > > > 
> > > > OK
> > > > 
> > > > So perhaps the question should be whether or not there is any viable approach
> > > > we can use to avoid or at least reduce the amount of all of the mostly manual
> > > > tuning to get as much battery life from systems as they can provide.  And that
> > > > cannot involve user space realistically, because some variants of it may just
> > > > not do whatever we expect them to do.
> > > 
> > > Tunables like those in i915 aren't going to be able to use any better
> > > approach, specifically because they don't work everywhere; if we had a
> > > list of systems they were safe on, we'd set up a quirk list and turn
> > > them on by default.  Do we have any tunables that *aren't* in that
> > > category?
> > 
> > I really don't think so, maybe except for some corner things.
> > 
> > > And if so, why don't we just set their defaults to DTRT?
> > 
> > But we seem to have more and more tunables for things that "don't work
> > everywhere", while at the same time the subset of systems where they *do* work
> > is quite substantial.
> > 
> > In many cases we simply don't have enough information to create a black or white
> > list for them, so we disable them by default and add a tunable to enable them
> > "in case someone needs" them.  This bothers me a bit, because it doesn't seem
> > to be sustainable in the long term.
> 
> I agree completely.
> 
> However, it seems like there's always enough information for a
> whitelist, if you know at least one system it works on.  Then people can
> submit patches extending the whitelist.
> 
> But in any case, this seems to argue against a global "use less power"
> switch, because any one of the underlying options might potentially
> break on the user's system.  Any that can be safely toggled by a master
> switch should just come pre-toggled. :)

Say the user has a new machine and doesn't know which tunables can be safely
enabled on it.  The only way to check is to toggle all of them and see if
anything breaks.  The difficulty here is that the user actually needs to
know about all of them which takes quite a bit of research and if nothing
breaks really that's a fair amount of work pretty much in vain.  A global
switch would make it somewhat easier for the lucky users whose systems
don't break after toggling it.

Thanks,
Rafael

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

[Josh Triplett]

On Sun, Jul 26, 2015 at 02:03:55AM +0200, Rafael J. Wysocki wrote:
> On Saturday, July 25, 2015 12:50:16 PM Josh Triplett wrote:
> > On Sat, Jul 25, 2015 at 12:36:18AM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, July 22, 2015 11:25:19 AM josh@joshtriplett.org wrote:
> > > > On Wed, Jul 22, 2015 at 07:25:40PM +0200, Rafael J. Wysocki wrote:
> > > > > On Wednesday, July 22, 2015 09:18:34 AM Daniel Vetter wrote:
> > > > > > On Wed, Jul 22, 2015 at 3:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > > > > On Tuesday, July 21, 2015 01:09:52 AM Daniel Vetter wrote:
> > > > > > >> On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > > > >> > On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
> > > > > > >> >> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> > > > > > >> >> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
> > > > > > >> >> >> But the kernel already has quirk tables for various hardware, and that
> > > > > > >> >> >> seems appropriate to continue putting in the kernel.
> > > > > > >> >> >
> > > > > > >> >> > For some types of devices, sure.  For others, like broken USB keyboards
> > > > > > >> >> > that can't handle autosuspend, no.  For those we need a userspace
> > > > > > >> >> > _whitelist_ that udev can use.  So there's no one answer that works for
> > > > > > >> >> > all types of quirks.
> > > > > > >> >>
> > > > > > >> >> Whether white or blacklist or some other mixed thing doesn't really
> > > > > > >> >> matter. Imo the important part is that driver maintainers are in the
> > > > > > >> >> best position to maintain that, and pushing it out to anyone else is
> > > > > > >> >> just really not doing our jobs. And I think for most of these quirk
> > > > > > >> >> lists the kernel does seem like the most appropriate place. If the
> > > > > > >> >> list becomes giantic then we can move it to userspace (if that's
> > > > > > >> >> really a problem, afaik no one proposed yet to move device match
> > > > > > >> >> tables into userspace either and that's kinda the same thing really).
> > > > > > >> >> But as long as there's no white/black/whatever list yet starting in
> > > > > > >> >> the kernel is imo the right place.
> > > > > > >> >
> > > > > > >> > Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
> > > > > > >> > for one example?
> > > > > > >> >
> > > > > > >> > Failing to enable it prevents some SoCs from using the deepest available
> > > > > > >> > C-states which in turn hurts battery life of the systems containing them
> > > > > > >> > quite a bit, so there surely is a reason to have it enabled.
> > > > > > >>
> > > > > > >> Because it's broken on a lot of machines, and it takes a pile of
> > > > > > >> effort to fix it.
> > > > > > >
> > > > > > > And there are quite a few subsystems having similar issues here and there.
> > > > > > >
> > > > > > > People who aren't aware of those command line/Kconfig/sysfs switches will
> > > > > > > never enable those features even though they may work well on their
> > > > > > > machines and may actually be necessary to save energy.
> > > > > > 
> > > > > > In my experience there's way too many people around who know about
> > > > > > these knobs but have no idea that they might be somewhat dangerous.
> > > > > > And then I get another bug report about a known bug just because
> > > > > > someone read a blog somewhere. Nowadays almost all i915 tuning knobs
> > > > > > are marked as _unsafe and taint your kernel if you touch them.
> > > > > > 
> > > > > > >> That work is under way now, but for a long time
> > > > > > >> priorities set by management where much more set on chasing the next
> > > > > > >> shiny thing. Took a few years of making noises about dropping it all
> > > > > > >> if it doesn't get fixed.
> > > > > > >>
> > > > > > >> This is actually a perfect example of what I mean with "hey it works
> > > > > > >> on my machine here, but I can't be bothered to fix up the corner-cases
> > > > > > >> so let's keep it disabled and move on". And the corner cases are hung
> > > > > > >> machines and frozen displays (and a few other things), and we
> > > > > > >> inflicted that a few times on Linus even.
> > > > > > >
> > > > > > > So among other things this topic is about a mechanism to possibly enable
> > > > > > > multiple things like that in one go instead of having to switch multiple
> > > > > > > knobs in various places (and needing to know about them in the first
> > > > > > > place).
> > > > > > 
> > > > > > I know, but at least for i915 I don't want it: When we know it's safe
> > > > > > to do we already enable all the power/performance tuning we have, and
> > > > > > if we know it's unsafe we don't want users to enable it themselves. If
> > > > > > you have a very specific product (which is not a generic distro or
> > > > > > anything) and have done careful testing and cross-checked with
> > > > > > developers then you can of course just enable these features. But then
> > > > > > you also don't need a new option, you can just change the driver
> > > > > > defaults directly.
> > > > > 
> > > > > OK
> > > > > 
> > > > > So perhaps the question should be whether or not there is any viable approach
> > > > > we can use to avoid or at least reduce the amount of all of the mostly manual
> > > > > tuning to get as much battery life from systems as they can provide.  And that
> > > > > cannot involve user space realistically, because some variants of it may just
> > > > > not do whatever we expect them to do.
> > > > 
> > > > Tunables like those in i915 aren't going to be able to use any better
> > > > approach, specifically because they don't work everywhere; if we had a
> > > > list of systems they were safe on, we'd set up a quirk list and turn
> > > > them on by default.  Do we have any tunables that *aren't* in that
> > > > category?
> > > 
> > > I really don't think so, maybe except for some corner things.
> > > 
> > > > And if so, why don't we just set their defaults to DTRT?
> > > 
> > > But we seem to have more and more tunables for things that "don't work
> > > everywhere", while at the same time the subset of systems where they *do* work
> > > is quite substantial.
> > > 
> > > In many cases we simply don't have enough information to create a black or white
> > > list for them, so we disable them by default and add a tunable to enable them
> > > "in case someone needs" them.  This bothers me a bit, because it doesn't seem
> > > to be sustainable in the long term.
> > 
> > I agree completely.
> > 
> > However, it seems like there's always enough information for a
> > whitelist, if you know at least one system it works on.  Then people can
> > submit patches extending the whitelist.
> > 
> > But in any case, this seems to argue against a global "use less power"
> > switch, because any one of the underlying options might potentially
> > break on the user's system.  Any that can be safely toggled by a master
> > switch should just come pre-toggled. :)
> 
> Say the user has a new machine and doesn't know which tunables can be safely
> enabled on it.  The only way to check is to toggle all of them and see if
> anything breaks.  The difficulty here is that the user actually needs to
> know about all of them which takes quite a bit of research and if nothing
> breaks really that's a fair amount of work pretty much in vain.  A global
> switch would make it somewhat easier for the lucky users whose systems
> don't break after toggling it.

Odds are at least one thing will break, though, and if the user doesn't
know about all of the tunables they just changed, they won't necessarily
know how to diagnose the reason, especially if the failure is more
subtle and doesn't completely break the system.

Perhaps, as a start towards this, we could document all the "might or
might not work" power management tunables in one place, and document
what might go wrong if they don't work on your system.  That could then
easily become an /etc/sysctl.d file to toggle them all.  And even if we
offer a single global "dangerous PM tunables" switch, that document
would help identify what might go wrong and help re-disable the things
that don't work.

- Josh Triplett

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

[Rafael J. Wysocki]

On Saturday, July 25, 2015 05:16:00 PM Josh Triplett wrote:
> On Sun, Jul 26, 2015 at 02:03:55AM +0200, Rafael J. Wysocki wrote:
> > On Saturday, July 25, 2015 12:50:16 PM Josh Triplett wrote:

[cut]

> > 
> > Say the user has a new machine and doesn't know which tunables can be safely
> > enabled on it.  The only way to check is to toggle all of them and see if
> > anything breaks.  The difficulty here is that the user actually needs to
> > know about all of them which takes quite a bit of research and if nothing
> > breaks really that's a fair amount of work pretty much in vain.  A global
> > switch would make it somewhat easier for the lucky users whose systems
> > don't break after toggling it.
> 
> Odds are at least one thing will break, though, and if the user doesn't
> know about all of the tunables they just changed, they won't necessarily
> know how to diagnose the reason, especially if the failure is more
> subtle and doesn't completely break the system.
> 
> Perhaps, as a start towards this, we could document all the "might or
> might not work" power management tunables in one place, and document
> what might go wrong if they don't work on your system.  That could then
> easily become an /etc/sysctl.d file to toggle them all.  And even if we
> offer a single global "dangerous PM tunables" switch, that document
> would help identify what might go wrong and help re-disable the things
> that don't work.

That sounds like a good idea to me.

Thanks,
Rafael

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

[Jani Nikula]

On Sat, 25 Jul 2015, Josh Triplett <josh@joshtriplett.org> wrote:
> On Sat, Jul 25, 2015 at 12:36:18AM +0200, Rafael J. Wysocki wrote:
>> On Wednesday, July 22, 2015 11:25:19 AM josh@joshtriplett.org wrote:
>> > On Wed, Jul 22, 2015 at 07:25:40PM +0200, Rafael J. Wysocki wrote:
>> > > On Wednesday, July 22, 2015 09:18:34 AM Daniel Vetter wrote:
>> > > > On Wed, Jul 22, 2015 at 3:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > > > > On Tuesday, July 21, 2015 01:09:52 AM Daniel Vetter wrote:
>> > > > >> On Tue, Jul 21, 2015 at 12:21 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > > > >> > On Friday, July 17, 2015 01:41:56 PM Daniel Vetter wrote:
>> > > > >> >> On Thu, Jul 16, 2015 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
>> > > > >> >> > On Thu, Jul 16, 2015 at 08:53:02AM -0700, Josh Triplett wrote:
>> > > > >> >> >> But the kernel already has quirk tables for various hardware, and that
>> > > > >> >> >> seems appropriate to continue putting in the kernel.
>> > > > >> >> >
>> > > > >> >> > For some types of devices, sure.  For others, like broken USB keyboards
>> > > > >> >> > that can't handle autosuspend, no.  For those we need a userspace
>> > > > >> >> > _whitelist_ that udev can use.  So there's no one answer that works for
>> > > > >> >> > all types of quirks.
>> > > > >> >>
>> > > > >> >> Whether white or blacklist or some other mixed thing doesn't really
>> > > > >> >> matter. Imo the important part is that driver maintainers are in the
>> > > > >> >> best position to maintain that, and pushing it out to anyone else is
>> > > > >> >> just really not doing our jobs. And I think for most of these quirk
>> > > > >> >> lists the kernel does seem like the most appropriate place. If the
>> > > > >> >> list becomes giantic then we can move it to userspace (if that's
>> > > > >> >> really a problem, afaik no one proposed yet to move device match
>> > > > >> >> tables into userspace either and that's kinda the same thing really).
>> > > > >> >> But as long as there's no white/black/whatever list yet starting in
>> > > > >> >> the kernel is imo the right place.
>> > > > >> >
>> > > > >> > Well, I'm wondering, then, why i915.enable_psr is not enabled by default,
>> > > > >> > for one example?
>> > > > >> >
>> > > > >> > Failing to enable it prevents some SoCs from using the deepest available
>> > > > >> > C-states which in turn hurts battery life of the systems containing them
>> > > > >> > quite a bit, so there surely is a reason to have it enabled.
>> > > > >>
>> > > > >> Because it's broken on a lot of machines, and it takes a pile of
>> > > > >> effort to fix it.
>> > > > >
>> > > > > And there are quite a few subsystems having similar issues here and there.
>> > > > >
>> > > > > People who aren't aware of those command line/Kconfig/sysfs switches will
>> > > > > never enable those features even though they may work well on their
>> > > > > machines and may actually be necessary to save energy.
>> > > > 
>> > > > In my experience there's way too many people around who know about
>> > > > these knobs but have no idea that they might be somewhat dangerous.
>> > > > And then I get another bug report about a known bug just because
>> > > > someone read a blog somewhere. Nowadays almost all i915 tuning knobs
>> > > > are marked as _unsafe and taint your kernel if you touch them.
>> > > > 
>> > > > >> That work is under way now, but for a long time
>> > > > >> priorities set by management where much more set on chasing the next
>> > > > >> shiny thing. Took a few years of making noises about dropping it all
>> > > > >> if it doesn't get fixed.
>> > > > >>
>> > > > >> This is actually a perfect example of what I mean with "hey it works
>> > > > >> on my machine here, but I can't be bothered to fix up the corner-cases
>> > > > >> so let's keep it disabled and move on". And the corner cases are hung
>> > > > >> machines and frozen displays (and a few other things), and we
>> > > > >> inflicted that a few times on Linus even.
>> > > > >
>> > > > > So among other things this topic is about a mechanism to possibly enable
>> > > > > multiple things like that in one go instead of having to switch multiple
>> > > > > knobs in various places (and needing to know about them in the first
>> > > > > place).
>> > > > 
>> > > > I know, but at least for i915 I don't want it: When we know it's safe
>> > > > to do we already enable all the power/performance tuning we have, and
>> > > > if we know it's unsafe we don't want users to enable it themselves. If
>> > > > you have a very specific product (which is not a generic distro or
>> > > > anything) and have done careful testing and cross-checked with
>> > > > developers then you can of course just enable these features. But then
>> > > > you also don't need a new option, you can just change the driver
>> > > > defaults directly.
>> > > 
>> > > OK
>> > > 
>> > > So perhaps the question should be whether or not there is any viable approach
>> > > we can use to avoid or at least reduce the amount of all of the mostly manual
>> > > tuning to get as much battery life from systems as they can provide.  And that
>> > > cannot involve user space realistically, because some variants of it may just
>> > > not do whatever we expect them to do.
>> > 
>> > Tunables like those in i915 aren't going to be able to use any better
>> > approach, specifically because they don't work everywhere; if we had a
>> > list of systems they were safe on, we'd set up a quirk list and turn
>> > them on by default.  Do we have any tunables that *aren't* in that
>> > category?
>> 
>> I really don't think so, maybe except for some corner things.
>> 
>> > And if so, why don't we just set their defaults to DTRT?
>> 
>> But we seem to have more and more tunables for things that "don't work
>> everywhere", while at the same time the subset of systems where they *do* work
>> is quite substantial.
>> 
>> In many cases we simply don't have enough information to create a black or white
>> list for them, so we disable them by default and add a tunable to enable them
>> "in case someone needs" them.  This bothers me a bit, because it doesn't seem
>> to be sustainable in the long term.
>
> I agree completely.
>
> However, it seems like there's always enough information for a
> whitelist, if you know at least one system it works on.  Then people can
> submit patches extending the whitelist.

Sadly, that assumes the whitelist (by DMI or PCI ID) of working systems
would be independent of the BIOS version or settings, which is not
always the case.

BR,
Jani.


>
> But in any case, this seems to argue against a global "use less power"
> switch, because any one of the underlying options might potentially
> break on the user's system.  Any that can be safely toggled by a master
> switch should just come pre-toggled. :)
>
> - Josh Triplett
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Jani Nikula, Intel Open Source Technology Center

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

[Kristen Accardi]

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

On Mon, Jul 6, 2015 at 6:45 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:

> On Monday, July 06, 2015 11:40:17 AM NeilBrown wrote:
> > On Mon, 06 Jul 2015 02:22:02 +0200 "Rafael J. Wysocki"
> > <rjw@rjwysocki.net> wrote:
> >
> > > Hi All,
> > >
> > > This is a re-occuring theme, but we discussed it last month during
> LinuxCon
> > > Japan with Kristen, Grant and other people and pretty much the only
> conclusion
> > > we could reach was to propose it as the KS topic, so here it goes.
> > >
> > > As systems get more and more complex and more and more internally
> integrated
> > > over time, every new generation of them requires an increased amount
> of tuning
> > > to achieve satisfactory balance between energy usage and performance.
> You need
> > > to know what to tune and how to do that, it needs to be done from user
> space or
> > > requires special Kconfig options to be set (or even out-of-the-tree
> patches to
> > > be applied in extreme cases) and so on.  All that becomes more and
> more esoteric
> > > and quite frankly I'm not sure how many users are able to do that on
> their new
> > > systems.
> > >
> > > That leads to a question whether or not a global interface
> (sysfs-based,
> > > command line etc.) could be added to the kernel that might be used to
> make a
> > > certain amount of the tuning happen already at the kernel level.  For
> example,
> > > it might change the default runtime PM control setting for all devices
> from
> > > "on" to "auto", automatically enable other runtime power management
> features
> > > available from various bus types (SATA link power management, USB LPM,
> others)
> > > and generally enable power management techiques disabled by default
> because
> > > enabling them may lead to performance regressions.
> > >
> > > So do we need such an interface?  If not, why not?  If so, how should
> it be
> > > designed, what should it cover etc.?
> > >
> >
> > This sounds like an important topic, but I don't think I quite
> > understand the question.
> > We already have ".../power/runtime_enabled" and various other tunables.
> > What more could you need in a kernel interface?
>
> The problem is that the defaults for all of those tunables are
> performance-oriented,
> so you need to flip many of them (if not all) to become power-oriented.
>
> That usually mean flipping a number of knobs every time you boot the
> system.
>
> > I can see that much more than an interface is needed - we need a tool
> > that makes use of that interface.
>
> That is one possible approach, but that tool would need to be developed in
> a lockstep with the kernel anyway, so it knows about all of the new
> features
> added to the kernel over time that have non-trivial power vs performance
> characteristics.
>

Deployment of a user space tool is the big issue - like Rafael said it is
hard to keep up with all the new settings that might be present and the
kernel will have this knowledge.


>
> > Maybe a database of different systems together with tuning settings for
> > different goals.
> > Then some tools detects the particular hardware it is running on, and
> > applies the tuning rules.
> >
> > (a tiny bit like a devicetree database which contains configuration
> > rules).
> >
> > Or have I missed the point completely?
>
> No, I don't think you have missed it, but then most of subsystems and
> drivers
> in the kernel know what it means to be "power-friendly", so they should be
> able
> to choose their defaults on the basis of one single setting somewhere.
>
> Thanks,
> Rafael
>
>
Also some components can be present on performance sensitive platforms as
well as power sensitive platforms, so it would be better if they chose
their default setting based on a system wide policy default that can be set
by a platform driver.


> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

[-- Attachment #2: Type: text/html, Size: 5240 bytes --]