# How many frequencies would cpufreq optimally like to manage?

• Subject: How many frequencies would cpufreq optimally like to manage?
• From: Mason <mpeg.blue@xxxxxxx>
• Date: Thu, 20 Nov 2014 00:24:30 +0100
• User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30

```Hello everyone,

I'm running kernel 3.14 on an ARM Cortex-A9 based SoC.
The baseline frequency for the ARM CPU is 999 MHz.

The SoC provides a way to dynamically change the CPU frequency,
dividing it by N/16 (N=32..4095) [Actually, I think there are
also ways to divide by 1.x, but I need to read the docs again.]

I'm writing the platform-specific cpufreq driver.
I could expose hundreds of frequencies to cpufreq, but I don't
think that would be very productive. Correct?
(Note: I can't offer ANY frequency.)

My question is: how many frequencies should I expose for "optimal"
behavior of cpufreq?

I'm thinking I would only expose div={2,3,5} meaning the available
scaled frequencies would be {500,333,200} MHz. Are these enough?
Should there be more? Should I go lower than 200 MHz?

I'm also wondering about the cpuinfo_transition_latency variable.
It seems to be a constant. On my SoC, the latency depends on the
"width" of the frequency jump. Specifically, the CPU will change
frequency at 15 MHz/us. So if we're jumping from 1000 to 500 MHz,
it will take 33 us. From 500 to 333 will take 11 us.

Should I document the max latency? (i.e. for the "widest" jump)
Can the governor request to jump from cpuinfo_min_freq to
cpuinfo_max_freq directly, skipping intermediate frequencies?
If so, should I just program

cpuinfo_transition_latency =
(((cpuinfo_max_freq - cpuinfo_min_freq) / 1000) / 15) * 1000

= (cpuinfo_max_freq - cpuinfo_min_freq) / 15 (in ns)
= 53280 ns in my example

Since governors.txt suggests a sampling rate of 10 ms, I suppose
a transition_latency of 50 us is acceptable?

Regards.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

```

[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]