cpu clock change latency

cpu clock change latency

[Marc Dietrich]

Hi,

arch/arm/mach-tegra/cpu-tegra.c (as from nv-tegra.nvidia.com) contains a some 
strange comment:

 493         /* FIXME: what's the actual transition time? */
 494         policy->cpuinfo.transition_latency = 300 * 1000;

The trees on chromeos.org (both, kernel and kernel-next) have:

 392         /* cpu clock change latency: ~400us */
 393         policy->cpuinfo.transition_latency = 400;

because according to 

http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=commitdiff;h=6a4debe346f5946f4fab14b413885896b7cde324

this improves latency of the GUI. Note that the comment said "us", while the cpu 
transition latency is measured in "ns", so 400 * 1000 would be right. 

So either the comment is wrong (should be 400ns) or the patch is wrong (which is 
unlikely, because it improved latency in the testcase).

Can someone comment on this?

Thanks

Marc

RE: cpu clock change latency

[Allen Martin]

> this improves latency of the GUI. Note that the comment said "us", while the
> cpu transition latency is measured in "ns", so 400 * 1000 would be right.
> 
> So either the comment is wrong (should be 400ns) or the patch is wrong
> (which is unlikely, because it improved latency in the testcase).
> 

You're right, the patch is wrong.  It should be 400us.  So the original code was much closer to the correct value.

The ondemand governor samples at 1000 times the transition latency, so it's not surprising it works fine with the wrong value at least with ondemand.  The interactive governor in android ignores transition latency.

Perhaps a better fix would be to make the hardcoded LATENCY_MULTIPLIER in the ondemand governor a tunable?

-Allen

Re: cpu clock change latency

[Colin Cross]

On Fri, Sep 23, 2011 at 7:39 AM, Marc Dietrich <marvin24-Mmb7MZpHnFY@public.gmane.org> wrote:
> Hi,
>
> arch/arm/mach-tegra/cpu-tegra.c (as from nv-tegra.nvidia.com) contains a some
> strange comment:
>
>  493         /* FIXME: what's the actual transition time? */
>  494         policy->cpuinfo.transition_latency = 300 * 1000;
>
> The trees on chromeos.org (both, kernel and kernel-next) have:
>
>  392         /* cpu clock change latency: ~400us */
>  393         policy->cpuinfo.transition_latency = 400;
>
> because according to
>
> http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=commitdiff;h=6a4debe346f5946f4fab14b413885896b7cde324
>
> this improves latency of the GUI. Note that the comment said "us", while the cpu
> transition latency is measured in "ns", so 400 * 1000 would be right.
>
> So either the comment is wrong (should be 400ns) or the patch is wrong (which is
> unlikely, because it improved latency in the testcase).
>
> Can someone comment on this?

cpu-tegra.c says latency is 300 uS because relocking the CPU pll has a
udelay(300).  400 nS would just make the ondemand governor sample more
often than it means to.  I doubt changing it to 400 uS makes any
difference.

> Thanks
>
> Marc
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: cpu clock change latency

[Mark Brown]

On Fri, Sep 23, 2011 at 09:49:53AM -0700, Colin Cross wrote:

> cpu-tegra.c says latency is 300 uS because relocking the CPU pll has a
> udelay(300).  400 nS would just make the ondemand governor sample more
> often than it means to.  I doubt changing it to 400 uS makes any
> difference.

The interactive effect of a higher transition latency with ondemand can
be rather visible.

It's probably also worth mentioning that if there's regulators used for
voltage scaling the system really ought to be including latency for them
in the estimate, for voltage increases the regulator needs to be updated
prior to the SoC side starting off.

Re: cpu clock change latency

[Marc Dietrich]

On Tuesday 27 September 2011 17:30:22 Mark Brown wrote:
> On Fri, Sep 23, 2011 at 09:49:53AM -0700, Colin Cross wrote:
> > cpu-tegra.c says latency is 300 uS because relocking the CPU pll has a
> > udelay(300).  400 nS would just make the ondemand governor sample more
> > often than it means to.  I doubt changing it to 400 uS makes any
> > difference.
> 
> The interactive effect of a higher transition latency with ondemand can
> be rather visible.

True, given the 400 µs latency and the multiplier of 1000 we end up having 
a sample_rate of the ondemand scheduler of 0.4 seconds, which is very 
"feelable". My AMD desktop announces a 1 µs latency so the default sampling 
rate is only 10 ms. 

A transition latency of 400 ns will set the sampling_rate to 10 ms (the 
minimum value allowed, so 10 µs would have the same effect). 

So doing an "echo 40000 > 
/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate" is the best we can 
do now and almost produces the same result as 10000. 

We additionaly found that setting io_is_busy=1 improves the transfer rate 
of the mmc by 50%. 

> It's probably also worth mentioning that if there's regulators used for
> voltage scaling the system really ought to be including latency for them
> in the estimate, for voltage increases the regulator needs to be updated
> prior to the SoC side starting off.

which would make things even worse :-(

Marc