On Wed, 3 Jul 2013 16:48:51 +0100 Renato Golin renato.golin@linaro.org wrote:
But more to the point, I don't want to be scaled down when hot, I want it never to get hot in the first place, so I can run at full 1.2GHz, 24 / 7. If the scheduler reduces the frequency to decrease the temperature, I'll be testing more commits per run AND my benchmarks will be skewed, depending on room temperature, which is the same as to say they're not benchmarks at all.
For getting reproducible benchmark results, you just need to ensure that thermal throttling never kicks in. If the kernel is compiled with cpufreq stats enabled, you can compare these stats before/after your benchmark to ensure that it spent all the time running at the same designated clock frequency.
If you get thermal throttling interfering, just keep reducing the CPU clock frequency until this problem disappears. Alternatively, you can possibly reduce the CPU core voltage, but this drives the hardware beyond normal operational limits. Or slightly increase the critical temperature in the thermal framework. However these tricks are only necessary if you need to publish something like "1.2GHz PandaBoard benchmark results" and the non-stock clock frequency is simply out of the question.
Anyway, I recommend you to start the tests for the hardware robustness with:
wget https://raw.github.com/ssvb/cpuburn/master/cpuburn-a9.S arm-linux-gnueabihf-gcc -o cpuburn-a9 cpuburn-a9.S
And then run it for exercising a really heavy multi-threaded workload on the CPU:
./cpuburn-a9
It would be also a good idea to verify that all the CPU cores are fully loaded.