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


Groups > linux.kernel > #1696802

Re: [PATCH V3 3/9] cpufreq: Cap the default transition delay value to 10 ms

From Viresh Kumar <viresh.kumar@linaro.org>
Newsgroups linux.kernel
Subject Re: [PATCH V3 3/9] cpufreq: Cap the default transition delay value to 10 ms
Date 2017-07-26 08:10 +0200
Message-ID <u7nGa-537-9@gated-at.bofh.it> (permalink)
References <u4Uff-79T-5@gated-at.bofh.it> <u4Ufi-79T-71@gated-at.bofh.it> <u7in8-1wt-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On 25-07-17, 14:54, Leonard Crestez wrote:

Thanks for reporting Leonard, really appreciate it.

> This patch made it's way into linux-next and it seems to cause imx socs
> to almost always hang around their max frequency with the ondemand
> governor, even when almost completely idle. The lowest frequency is
> never reached. This seems wrong?

Sure thing. Though I tried to reproduce it on Hikey today and it all
worked pretty fine with ondemand governor. The latency is around 500
us here. I don't have a clue right now on what's wrong in your setup.

> This driver calculates transition_latency at probe time, the value is
> not terribly accurate but it reaches values like latency = 109 us, so

So this is the value that is stored in the global variable
"transition_latency" in the imx6q-cpufreq.c file? i.e.
transition_latency = 109000 (ns) to be exact ?

> this patch clamps it at about 10% of the value.

Without this patch the sampling rate of ondemand governor will be 109
ms. And after this patch it would be capped at 10 ms. Why would that
screw up anyone's setup ? I don't have an answer to that right now.

> It's worth noting that the default IMX config has HZ=100 and
> NO_HZ_IDLE=y, so maybe doing idle checks at a rate comparable to the
> jiffie tick screws stuff up?

Maybe, but I am not sure at all.

Can you try few things ?

- Don't use this patch and try to change ondemand's sampling rate from
  sysfs. Try setting it to 10000 and see if the behavior is identical
  to after this patch.

- Find how much time does it really take to change the frequency of
  the CPU. I don't really thing 109 us is the right transition
  latency. Use attached patch for that and look for the print message.

-- 
viresh

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH V3 3/9] cpufreq: Cap the default transition delay value to 10 ms Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-19 12:20 +0200
  Re: [PATCH V3 3/9] cpufreq: Cap the default transition delay value to 10 ms "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-07-26 02:30 +0200
  Re: [PATCH V3 3/9] cpufreq: Cap the default transition delay value  to 10 ms Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-26 08:10 +0200
    Re: [PATCH V3 3/9] cpufreq: Cap the default transition delay value  to 10 ms Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-28 07:30 +0200

csiph-web