lkml.org 
[lkml]   [2016]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] thermal: re-calculate k_po/k_pu when update sustainable power
From
Date
On 05/01/16 16:33, Javi Merino wrote:
> On Mon, Jan 04, 2016 at 11:22:26AM +0000, Daniel Thompson wrote:
>> On 01/01/16 00:03, Leo Yan wrote:
>>> Hi Eduardo,
>>>
>>> Thanks for review.
>>>
>>> On Thu, Dec 31, 2015 at 09:21:26AM -0800, Eduardo Valentin wrote:
>>>> On Wed, Dec 30, 2015 at 06:38:40PM +0800, Leo Yan wrote:
>>>>> k_po/k_pu are in essence ratio values compared with sustainable power.
>>>>> So when update sustainable power, we can recalculate k_po/k_pu simply
>>>>> with below formula:
>>>>>
>>>>> sustainable_power(new)
>>>>> k_p(new) = ---------------------- * k_p(old)
>>>>> sustainable_power(old)
>>>>>
>>>>> Signed-off-by: Leo Yan <leo.yan@linaro.org>
>>>>> ---
>>>>> drivers/thermal/thermal_core.c | 6 +++++-
>>>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>>>>> index d9e525c..223f8df 100644
>>>>> --- a/drivers/thermal/thermal_core.c
>>>>> +++ b/drivers/thermal/thermal_core.c
>>>>> @@ -908,7 +908,7 @@ sustainable_power_store(struct device *dev, struct device_attribute *devattr,
>>>>> const char *buf, size_t count)
>>>>> {
>>>>> struct thermal_zone_device *tz = to_thermal_zone(dev);
>>>>> - u32 sustainable_power;
>>>>> + u32 sustainable_power, old_val;
>>>>>
>>>>> if (!tz->tzp)
>>>>> return -EIO;
>>>>> @@ -916,8 +916,12 @@ sustainable_power_store(struct device *dev, struct device_attribute *devattr,
>>>>> if (kstrtou32(buf, 10, &sustainable_power))
>>>>> return -EINVAL;
>>>>>
>>>>> + old_val = tz->tzp->sustainable_power;
>>>>> +
>>>>> tz->tzp->sustainable_power = sustainable_power;
>>>>>
>>>>> + tz->tzp->k_po = (tz->tzp->k_po * sustainable_power) / old_val;
>>>>> + tz->tzp->k_pu = (tz->tzp->k_pu * sustainable_power) / old_val;
>>>>
>>>> I believe this has to be done by the governor. These properties are
>>>> power_allocator specific. thermal_core should not really care about
>>>> them.
>>>
>>> Okay, I will try to update these properties in power_allocator.c.
>>> Javi, do you think this is fine for you?
>>
>> If sustainable power were to change frequently (perhaps on
>> entry/exit of a fan inhibitor mode?) then we would accumulate
>> rounding errors here...
>
> Can you elaborate on the use case? What is this fan inhibitor mode?

It's made up.

I was trying to think of use cases which might result in the userspace
wishing to make frequent changes the maximum sustainable power. For
designs where the system remains thermally overcommited even with the
fan running then having a mode where the fan must not spin up would
require such a change.

Inhibiting the fan could be useful for:

1. A distraction-free mode for a laptop. One of the more elderly
laptops in my household tends to spin up its fans as a background
process indexes the disc which can be annoying (but not quite
annoying enough for me to actually try and implement a fan
inhibition mode).

2. A way to ensure a set-top box, game console or other device that is
"off" can do background processing without risking bursts of CPU
activity that makes the fan spin up.


Daniel.


\
 
 \ /
  Last update: 2016-01-05 18:41    [W:0.156 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site