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
next prev parent 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