(changing subject, +eas-dev)
On 10/19/2015 12:34 AM, Vincent Guittot wrote:
FWIW as I tested with the browser-short rt-app workload I noticed the
rt-app calibration causes the CPU frequency to oscillate between fmin and fmax.
It's a normal behavior. During calibration step, we try to force the governor to use the max OPP to evaluate the minimum ns per loop. We have 2 sequence: The 1st one just loop on the calibration loop until the ns per loop value reach a stable value. The second one alternate run and sleep phase to prevent the trig of thermal mitigation which can be triggered during 1 sequence
Understood that rt-app would want to hit fmax for calibration, but the oscillation directly between fmin and fmax, and the timing of the transitions, seem concerning.
I've copied a trace of this to http://smuckle.net/calibrate.txt . As an example at ~41.808:
- rt-app starts executing and executes continuously at fmin for about 85ms. That's a long time IMO to underserve a continuously running workload before changing frequency.
- The frequency then goes directly to fmax and rt-app runs for 3ms more. We should be going to an intermediate frequency first. This has come up on lkml and I think everyone wants that change but I'm including it here for completeness.
- The system then sits idle at fmax for almost 200ms since nothing is decaying the usage on the idle CPU. This also came up on lkml though it's probably worth mentioning that it's so easy to reproduce with rt-app.
Just curious, is rt-app doing a fixed amount of work in these bursts of execution? Or is it watching cpufreq nodes so that it knows when the CPU frequency has hit fmax, so it can then do calibration work?
On 19 October 2015 at 20:11, Steve Muckle steve.muckle@linaro.org wrote:
(changing subject, +eas-dev)
On 10/19/2015 12:34 AM, Vincent Guittot wrote:
FWIW as I tested with the browser-short rt-app workload I noticed the
rt-app calibration causes the CPU frequency to oscillate between fmin and fmax.
It's a normal behavior. During calibration step, we try to force the governor to use the max OPP to evaluate the minimum ns per loop. We have 2 sequence: The 1st one just loop on the calibration loop until the ns per loop value reach a stable value. The second one alternate run and sleep phase to prevent the trig of thermal mitigation which can be triggered during 1 sequence
Understood that rt-app would want to hit fmax for calibration, but the oscillation directly between fmin and fmax, and the timing of the transitions, seem concerning.
I've copied a trace of this to http://smuckle.net/calibrate.txt . As an example at ~41.808:
- rt-app starts executing and executes continuously at fmin for about
85ms. That's a long time IMO to underserve a continuously running workload before changing frequency.
- The frequency then goes directly to fmax and rt-app runs for 3ms more.
We should be going to an intermediate frequency first. This has come up on lkml and I think everyone wants that change but I'm including it here for completeness.
- The system then sits idle at fmax for almost 200ms since nothing is
decaying the usage on the idle CPU. This also came up on lkml though it's probably worth mentioning that it's so easy to reproduce with rt-app.
Just curious, is rt-app doing a fixed amount of work in these bursts of execution? Or is it watching cpufreq nodes so that it knows when the CPU frequency has hit fmax, so it can then do calibration work?
It's a fix amount of work and rt-app doesn't monitored the CPU frequency. Nevertheless, the amount of work is not the same between each step to prevent any sync effect with the sampling rate of the cpufreq governor as an example
Regards, Vincent
-
Steve Muckle -
Vincent Guittot