ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: "Brown, Len" <len.brown@intel.com>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Ksummit-discuss] [TECH(CORE?) TOPIC] Energy conservation bias interfaces
Date: Wed, 14 May 2014 11:15:30 +0200	[thread overview]
Message-ID: <53733432.5050106@linaro.org> (raw)
In-Reply-To: <4212156.95Ek3E3WsK@vostro.rjw.lan>

On 05/14/2014 01:41 AM, Rafael J. Wysocki wrote:
> On Monday, May 12, 2014 10:43:22 PM Preeti U Murthy wrote:
>> On 05/12/2014 04:44 PM, Morten Rasmussen wrote:
>>> On Thu, May 08, 2014 at 09:59:39AM +0100, Preeti U Murthy wrote:
>>>> On 05/07/2014 10:50 AM, Iyer, Sundar wrote:
>
> [cut]
>
>>> While I agree that there are mechanisms to deal with thermal throttling
>>> already, I think it is somewhat related to energy-awareness. If you need
>>> throttling due to thermal constraints you are burning too much power in
>>> your system. If you factor in energy-effiency and the requirements for
>>> the current use-case you might be able to stay within the power budget
>>> with a smaller performance impact than blindly throttling all
>>> subsystems.
>>
>> True. I was intending to distinguish the who and the why in the above
>> two situations. My only point was that thermal throttling is undertaken
>> by platform and is a safety mechanism whereas switching to energy saving
>> mode when battery is low is undertaken by the kernel and will lead to
>> better end-user experience i.e.battery longevity. Yes the kernel is
>> expected to prevent the system from being throttled as much as possible.
>
> The kernel may very well be responsible for thermal throttling in some cases.
> At least it needs to be able to respond to "do not draw more power than this"
> type of requests.
>
> [cut]
>
>>>
>>> IIUC, you are proposing to have profiles setting a lot of kernel
>>> tunables rather than a single knob to control energy-awareness?
>>>
>>> My concern with profiles is that it basically exports most of the
>>> energy-awareness decision problems to user-space. Maybe I'm missing
>>> something? IMHO, it would be better to have more accurate energy related
>>> topology information in the kernel so it would be able to take the
>>> decisions.
>>
>> You are right. We shouldn't be exposing so many knobs to user-space and
>> expect the kernel to make good decisions based on these knobs being
>> tweaked by user space. How about a high level classification of profiles
>> like balanced, performance, powersave? These alone can be chosen by the
>> user and the lower end tunings left to the discretion of the kernel.
>
> Well, so we're actually back to a central knob with three levels effectively. :-)

May be we can consider adding the large number of knobs with debugfs ?


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

  reply	other threads:[~2014-05-14  9:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-07  5:20 Iyer, Sundar
2014-05-08  8:59 ` Preeti U Murthy
2014-05-08 14:23   ` Iyer, Sundar
2014-05-12 10:31     ` Morten Rasmussen
2014-05-12 10:55       ` Iyer, Sundar
2014-05-13 23:48         ` Rafael J. Wysocki
2014-05-12 16:06     ` Preeti U Murthy
2014-05-13 23:29       ` Rafael J. Wysocki
2014-05-12 11:14   ` Morten Rasmussen
2014-05-12 17:13     ` Preeti U Murthy
2014-05-12 17:30       ` Iyer, Sundar
2014-05-13  6:28       ` Amit Kucheria
2014-05-13 23:41       ` Rafael J. Wysocki
2014-05-14  9:15         ` Daniel Lezcano [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-05-06 12:54 Rafael J. Wysocki
2014-05-06 13:37 ` Dave Jones
2014-05-06 13:49 ` Peter Zijlstra
2014-05-06 14:51   ` Morten Rasmussen
2014-05-06 15:39     ` Peter Zijlstra
2014-05-06 16:04       ` Morten Rasmussen
2014-05-08 12:29   ` Rafael J. Wysocki
2014-05-06 14:34 ` Morten Rasmussen
2014-05-06 17:51 ` Preeti U Murthy
2014-05-08 12:58   ` Rafael J. Wysocki
2014-05-08 14:57     ` Iyer, Sundar
2014-05-12 16:44       ` Preeti U Murthy
2014-05-13 23:36         ` Rafael J. Wysocki
2014-05-15 10:37           ` Preeti U Murthy
2014-05-10 16:59     ` Preeti U Murthy
2014-05-07 21:03 ` Paul Gortmaker
2014-05-12 11:53 ` Amit Kucheria
2014-05-12 12:31   ` Morten Rasmussen
2014-05-13  5:52     ` Amit Kucheria
2014-05-13  9:59       ` Morten Rasmussen
2014-05-13 23:55         ` Rafael J. Wysocki
2014-05-14 20:21           ` Daniel Vetter
2014-05-12 20:58   ` Mark Brown

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=53733432.5050106@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=len.brown@intel.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rjw@rjwysocki.net \
    /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