RE: Regression in TEO cpuidle governor between 6.6 and 6.12

["Doug Smythies" <dsmythies@telus.net>]

Hi Christian,

This email is about testing as opposed to about the subject and patches.
Specifically, the " adrestia" test.

On 2025.11.13 07:43 Christian wrote:
...
> Forgot to post the full results, anyway as expected with mtdblock (a very slow
> / low frequent wakeup scenario) the impact becomes clearly visible.
> Still hopeful that the more conservative approach will be acceptable!
...
> test       gov        i     score  %change    idles  idle_miss  miss_rt   belows   aboves
...
> adrestia   teo-m      0         8    0     103680         21      0.000         19          2   <<<<
> adrestia   teo-m      1        12   50     104026         31      0.000         16         15
> adrestia   teo-m      2        12   50     104063         32      0.000         24          8
> adrestia   teo-m      3        12   50     104768         44      0.000         22         22
> adrestia   teo-m      4        12   50     104388         18      0.000         16          2

> adrestia   teo-patch  0        12   50     103096         67      0.001         65          2
> adrestia   teo-patch  1        12   50     103128         57      0.001         49          8
> adrestia   teo-patch  2         8    0     102812         78      0.001         72          6    <<<<
> adrestia   teo-patch  3        12   50     102990         60      0.001         55          5
> adrestia   teo-patch  4        12   50     103168         24      0.000         24          0
...

I am curious about the significant variations between iterations for your
adrestia test. And what does "score" mean for this test?

I don't know if we are running the exact same test [1], but my "score" means
wakeup cost (periodic, 20us), and for the 6.18-rc4 kernel is around 2.7 uSec,
independent of the various patches or teo verses menu governors.
My results are very repeatable.
With kernel 6.13 I was getting 3.3 uSec, but I suspect the differences
have more to do with other kernel changes than any idle governor changes.

My typical testing command line is:

./adrestia -a 20 -l 2000000 -t 500 wakeup-periodic

Where:
-a      arrival time (microseconds) << Only used for periodic test, sleep time. Actually arrival rate.
-l      number of loops
-L      list tests  << wakeup-periodic and wakeup-single
-s      service time (microseconds) << This has not been implemented.
-t      thread count

Those run parameters give a reasonable amount of idle time using
both idle states 0 and 1.

[1] It is likely we are not running the exact same test, since I converted the
source code I use from uSec to nSec. Notes to myself from a couple of
years ago suggest that I am using the version from [2] and that the version
from [3] does not compile (at least for me).

[2] https://github.com/notcarbide/adrestia
[3] https://github.com/mfleming/adrestia

... Doug