From: Josh Triplett <josh@joshtriplett.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Brown, Len" <len.brown@intel.com>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
Alan Stern <stern@rowland.harvard.edu>,
Kristen Carlson Accardi <kristen@linux.intel.com>,
Grant Likely <grant.likely@linaro.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] System-wide interface to specify the level of PM tuning
Date: Wed, 15 Jul 2015 18:10:56 -0700 [thread overview]
Message-ID: <20150716011056.GA8931@x> (raw)
In-Reply-To: <2869041.AWiygZspUy@vostro.rjw.lan>
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
next prev parent reply other threads:[~2015-07-16 1:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-06 0:22 [Ksummit-discuss] [TECH TOPIC] System-wide interface to specify the level of PM tuning Rafael J. Wysocki
2015-07-06 1:21 ` Josh Triplett
2015-07-06 14:04 ` Rafael J. Wysocki
2015-07-06 1:40 ` NeilBrown
2015-07-06 14:12 ` Rafael J. Wysocki
2015-07-06 13:49 ` Iyer, Sundar
2015-07-06 14:21 ` Rafael J. Wysocki
2015-07-07 7:53 ` Jiri Kosina
2015-07-07 12:33 ` Rafael J. Wysocki
2015-07-10 17:25 ` Kevin Hilman
2015-07-12 10:01 ` Daniel Vetter
2015-07-13 23:07 ` Rafael J. Wysocki
2015-07-14 16:51 ` Daniel Vetter
2015-07-15 22:44 ` Rafael J. Wysocki
2015-07-16 1:10 ` Josh Triplett [this message]
2015-07-16 9:19 ` David Woodhouse
2015-07-16 15:44 ` Kristen Accardi
2015-07-16 15:53 ` Josh Triplett
2015-07-16 15:58 ` Greg KH
2015-07-17 10:34 ` Takashi Iwai
2015-07-17 11:41 ` Daniel Vetter
2015-07-20 22:21 ` Rafael J. Wysocki
2015-07-20 23:09 ` Daniel Vetter
2015-07-22 1:12 ` Rafael J. Wysocki
2015-07-22 7:18 ` Daniel Vetter
2015-07-22 17:25 ` Rafael J. Wysocki
2015-07-22 18:25 ` josh
2015-07-24 22:36 ` Rafael J. Wysocki
2015-07-25 19:50 ` Josh Triplett
2015-07-26 0:03 ` Rafael J. Wysocki
2015-07-26 0:16 ` Josh Triplett
2015-07-27 13:30 ` Rafael J. Wysocki
2015-07-27 11:50 ` Jani Nikula
2015-07-06 16:33 ` Kristen Accardi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150716011056.GA8931@x \
--to=josh@joshtriplett.org \
--cc=grant.likely@linaro.org \
--cc=kristen@linux.intel.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=len.brown@intel.com \
--cc=rjw@rjwysocki.net \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.