Comment 2 for bug 2051342

Before my post yesterday, I had never used the stress-ng utility, and only did so to repeat the originally posted test case. However, there was run to run variability with the stress-ng test that I could not understand for a 100% user, 0% system, type program. I decided to retest using one my own CPU loading programs. I also did only 1 thread and forced CPU affinity.

I also tried to get a more accurate estimate of the tick ISR execution time. Trace only does time stamping to the microsecond, making it difficult. For the 1000Hz kernel and a 100 second trace, 100000 tick ISRs were captured. min 0, average 0.7, max 2 uSec.

250Hz kernel test time (less is better): 300.14 seconds (100% user 0% system).

For the 1000 Hertz kernel the extra execution time prediction is:
0.7 uSec/tick * 750 extra ticks/sec * 300.14 sec = 0.16 sec
For a predicted execution time of 300.30 seconds.

1000Hz kernel test time: 300.32 seconds.

1000Hz+nohz_full test time: 300.08 seconds.

In an attempt to get a better model the processor CPU frequency was changed from 4.8 GHz to 0.80 GHz.
Tick ISR: min 3, average 4.0, max 11 uSec.
Note: of the 100000 tick ISRs captured the 11 uSec one was a one time outlier.

250Hz kernel test time: 429.25

For the 1000 Hertz kernel the extra execution time prediction is:
4.0 uSec/tick * 750 extra ticks/sec * 429.25 sec = 1.29 sec
For a predicted execution time of 430.53 seconds.

1000Hz kernel test time: 430.38 seconds.