Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1677372 > unrolled thread

Re: [PATCH] cpufreq: Find transition latency dynamically

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] cpufreq: Find transition latency dynamically Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-29 06:30 +0200
    Re: [PATCH] cpufreq: Find transition latency dynamically "Rafael J. Wysocki" <rafael@kernel.org> - 2017-06-29 22:40 +0200
      Re: [PATCH] cpufreq: Find transition latency dynamically Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-30 06:00 +0200

#1677372 — Re: [PATCH] cpufreq: Find transition latency dynamically

On 02-06-17, 16:59, Viresh Kumar wrote:
> The transition_latency_ns represents the maximum time it can take for
> the hardware to switch from/to any frequency for a CPU.
> 
> The transition_latency_ns is used currently for two purposes:
> 
> o To check if the hardware latency is over the maximum allowed for a
>   governor (only for ondemand and conservative (why not schedutil?)) and
>   to decide if the governor can be used or not.
> 
> o To calculate the sampling_rate or rate_limit for the governors by
>   multiplying transition_latency_ns with a constant.
> 
> The platform drivers can also set this value to CPUFREQ_ETERNAL if they
> don't know this number and in that case we disallow use of ondemand and
> conservative governors as the latency would be higher than the maximum
> allowed for the governors.
> 
> In many cases this number is forged by the driver authors to get the
> default sampling rate to a desired value. Anyway, the actual latency
> values can differ from what is received from the hardware designers.
> 
> Over that, what is provided by the drivers is most likely the time it
> takes to change frequency of the hardware, which doesn't account the
> software overhead involved.
> 
> In order to have guarantees about this number, this patch tries to
> calculate the latency dynamically at cpufreq driver registration time by
> first switching to min frequency, then to the max and finally back to
> the initial frequency. And the maximum of all three is used as the
> target_latency. Specifically the time it takes to go from min to max
> frequency (when the software runs the slowest) should be good enough,
> and even if there is a delta involved then it shouldn't be a lot.
> 
> For now this patch limits this feature only for platforms which have set
> the transition latency to CPUFREQ_ETERNAL. Maybe we can convert everyone
> to use it in future, but lets see.
> 
> This is tested over ARM64 Hikey platform which currently sets
> "clock-latency" as 500 us from DT, while with this patch the actualy
> value increased to 800 us.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  drivers/cpufreq/cpufreq.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)

Hi Rafael,

Any inputs on this one ?

-- 
viresh

[toc] | [next] | [standalone]

#1678180

On Thu, Jun 29, 2017 at 6:28 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 02-06-17, 16:59, Viresh Kumar wrote:
>> The transition_latency_ns represents the maximum time it can take for
>> the hardware to switch from/to any frequency for a CPU.
>>
>> The transition_latency_ns is used currently for two purposes:
>>
>> o To check if the hardware latency is over the maximum allowed for a
>>   governor (only for ondemand and conservative (why not schedutil?)) and
>>   to decide if the governor can be used or not.
>>
>> o To calculate the sampling_rate or rate_limit for the governors by
>>   multiplying transition_latency_ns with a constant.
>>
>> The platform drivers can also set this value to CPUFREQ_ETERNAL if they
>> don't know this number and in that case we disallow use of ondemand and
>> conservative governors as the latency would be higher than the maximum
>> allowed for the governors.
>>
>> In many cases this number is forged by the driver authors to get the
>> default sampling rate to a desired value. Anyway, the actual latency
>> values can differ from what is received from the hardware designers.
>>
>> Over that, what is provided by the drivers is most likely the time it
>> takes to change frequency of the hardware, which doesn't account the
>> software overhead involved.
>>
>> In order to have guarantees about this number, this patch tries to
>> calculate the latency dynamically at cpufreq driver registration time by
>> first switching to min frequency, then to the max and finally back to
>> the initial frequency. And the maximum of all three is used as the
>> target_latency. Specifically the time it takes to go from min to max
>> frequency (when the software runs the slowest) should be good enough,
>> and even if there is a delta involved then it shouldn't be a lot.
>>
>> For now this patch limits this feature only for platforms which have set
>> the transition latency to CPUFREQ_ETERNAL. Maybe we can convert everyone
>> to use it in future, but lets see.
>>
>> This is tested over ARM64 Hikey platform which currently sets
>> "clock-latency" as 500 us from DT, while with this patch the actualy
>> value increased to 800 us.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> ---
>>  drivers/cpufreq/cpufreq.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 63 insertions(+)
>
> Hi Rafael,
>
> Any inputs on this one ?

Shouldn't drivers do that really?

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1678443

On 29-06-17, 22:34, Rafael J. Wysocki wrote:
> Shouldn't drivers do that really?

Well they can, but the we will have some sort of code duplication
then. Or else we can provide a helper for them to find this value
dynamically and that would be fine too. And maybe we can add a
callback for the cpufreq-driver, which can be filled by the generic
helper and core can call it once at policy initialization time.

-- 
viresh

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web