ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Grant Likely <grant.likely@linaro.org>,
	Len Brown <len.brown@intel.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Kristen Carlson Accardi <kristen@linux.intel.com>,
	ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] System-wide interface to specify the level of PM tuning
Date: Mon, 06 Jul 2015 16:04:13 +0200	[thread overview]
Message-ID: <2103508.4Lqs6zjrJu@vostro.rjw.lan> (raw)
In-Reply-To: <20150706012125.GC15108@x>

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

  reply	other threads:[~2015-07-06 13:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-06  0:22 Rafael J. Wysocki
2015-07-06  1:21 ` Josh Triplett
2015-07-06 14:04   ` Rafael J. Wysocki [this message]
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
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=2103508.4Lqs6zjrJu@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=grant.likely@linaro.org \
    --cc=josh@joshtriplett.org \
    --cc=kristen@linux.intel.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=len.brown@intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox