linux-kernel - Re: [PATCH] cpuidle/drivers/mobile: Add new governor for mobile/embedded systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 3 Jul 2019 17:16:13 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Doug Smythies <dsmythies@...us.net>
Cc:     linux-kernel@...r.kernel.org,
        "'Rafael J. Wysocki'" <rjw@...ysocki.net>,
        'Thomas Gleixner' <tglx@...utronix.de>,
        'Greg Kroah-Hartman' <gregkh@...uxfoundation.org>,
        "'open list:CPU IDLE TIME MANAGEMENT FRAMEWORK'" 
        <linux-pm@...r.kernel.org>, rafael@...nel.org
Subject: Re: [PATCH] cpuidle/drivers/mobile: Add new governor for
 mobile/embedded systems


Hi Doug,

On 03/07/2019 16:23, Doug Smythies wrote:
> Hi Daniel,
> 
> I tried your "mobile" governor, albeit not on a mobile device.
> 
> On 2019.06.20 04:58 Daniel Lezcano wrote:
> 
> ...
> 
>> The mobile governor is a new governor targeting embedded systems
>> running on battery where the energy saving has a higher priority than
>> servers or desktops. This governor aims to save energy as much as
>> possible but with a performance degradation tolerance.
>>
>> In this way, we can optimize the governor for specific mobile workload
>> and more generally embedded systems without impacting other platforms.
> 
> I just wanted to observe the lower energy, accepting performance
> degradation. My workloads may have been inappropriate.

Thanks for trying the governor. It is still basic but will be improved
step by step regarding clearly identified workload and with more help
from the scheduler. This is the first phase of the governor providing
the base bricks.

>> +
>> +#define EMA_ALPHA_VAL		64
>> +#define EMA_ALPHA_SHIFT		7
>> +#define MAX_RESCHED_INTERVAL_MS	100
>> +
>> +static DEFINE_PER_CPU(struct mobile_device, mobile_devices);
>> +
>> +static int mobile_ema_new(s64 value, s64 ema_old)
>> +{
>> +	if (likely(ema_old))
>> +		return ema_old + (((value - ema_old) * EMA_ALPHA_VAL) >>
>> +				  EMA_ALPHA_SHIFT);
>> +	return value;
>> +}
> 
> Do you have any information as to why these numbers?
>
> Without any background, the filter seems overly new value weighted to me.
> It is an infinite impulse response type filter, currently at:
> 
> output = 0.5 * old + 0.5 * new.
> 
> I tried, but didn't get anything conclusive:
> 
> output = 0.875 * old + 0.125 * new.
> 
> I did it this way:
> 
> #define EMA_ALPHA_VAL           7
> #define EMA_ALPHA_SHIFT         3
> #define MAX_RESCHED_INTERVAL_MS 100

Ok, I will have a look at these values.

> static DEFINE_PER_CPU(struct mobile_device, mobile_devices);
> 
> static int mobile_ema_new(s64 value, s64 ema_old)
> {
>         if (likely(ema_old))
>                 return ((ema_old * EMA_ALPHA_VAL) + value) >>
>                                   EMA_ALPHA_SHIFT;
>         return value;
> }
> 
> ...
> 
>> +	/*
>> +	 * Sum all the residencies in order to compute the total
>> +	 * duration of the idle task.
>> +	 */
>> +	residency = dev->last_residency - s->exit_latency;
> 
> What about when the CPU comes out of the idle state before it
> even gets fully into it? Under such conditions it seems to hold
> much too hard at idle states that are too deep, to the point
> where energy goes up while performance goes down.

I'm not sure there is something we can do here :/


> Anyway, I did a bunch of tests and such, but have deleted
> most from this e-mail, because it's just noise. I'll
> include just one set:
> 
> For a work load that would normally result in a lot of use
> of shallow idle states (single core pipe-test * 2 cores).

Can you share the tests and the command lines?


> I got (all kernel 5.2-rc5 + this patch):
> 
> Idle governor, teo; CPU frequency scaling: intel-cpufreq/ondemand;
> Processor package power: 40.4 watts; 4.9 uSec/loop
> 
> Idle governor, teo; CPU frequency scaling: intel-cpufreq/ondemand;
> Processor package power: 34 watts; 5.2 uSec/loop
> 
> Idle governor, mobile; CPU frequency scaling: intel-cpufreq/ondemand;
> Processor package power: 25.9 watts; 11.1 uSec/loop
> 
> Idle governor, menu; CPU frequency scaling: intel-cpufreq/ondemand;
> Processor package power: 34.2 watts; 5.23 uSec/loop
> 
> Idle governor, teo; CPU frequency scaling: intel-cpufreq/ondemand;
> Maximum CPU frequency limited to 73% to match mobile energy.
> Processor package power: 25.4 watts; 6.4 uSec/loop

Ok that's interesting. Thanks for the values.

The governor can be better by selecting the shallow states, the
scheduler has to interact with the governor to give clues about the
load, that is identified and will be the next step.

Is it possible to check with the schedutil governor instead?



-- 
 <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