RE: [PATCH v1 0/5] cpuidle: governors: teo: Wakeup events classification change and some refinements

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

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

Hi All,

I have been testing this series, but have nothing significant to report, so far.

On 2026.01.19 Rafael J. Wysocki wrote:
>On Mon, Jan 19, 2026 at 10:53 AM Christian Loehle wrote:
>> On 1/16/26 12:29, Rafael J. Wysocki wrote:
>>> On Fri, Jan 16, 2026 at 12:52 PM Christian Loehle wrote:
>>>> On 1/14/26 19:42, Rafael J. Wysocki wrote:

...snip...

>>>> There's a regression on teo-4 visible on the intercept heavy IO workloads,
>>>> for idle misses that isn't strong enough to reflect in score changes except
>>>> for the very slow mtdblock device.
>>>> interestingly though there also seems to be a regression in
>>>> mapper/dm-slow (dm device with 51ms delay on each IO), which is not
>>>> intercept heavy.
>>>> Looking at the state residencies it overuses the deepest state2 in
>>>> where state1 was preferred for the other teo variants.

I did observe similar in one test, an increase in the use of idle
state 2. The relevant graphs are attached.

Legend:
rc5 = kernel 6.19-rc5
rjw = kernel 6.19-rc5 + this 5 patch set.

Workflow:
My version of "critical-jobs", an attempt to do similar to the non-free SPECjbb (that Artem sometimes reports on).
Sweep from 4000 to 4600 jobs per second, and 10 disk lookups per job,
and "500" (arbitrary) units of work per lookup. 500 Gigabyte data file:
While "rc5" completed considerably faster than "rjw", I don't yet know if it is repeatable.

... snip ...

... Doug


[-- Attachment #2: 0_residency.png --]
[-- Type: image/png, Size: 57204 bytes --]

[-- Attachment #3: 1_residency.png --]
[-- Type: image/png, Size: 57785 bytes --]

[-- Attachment #4: 2_above.png --]
[-- Type: image/png, Size: 56239 bytes --]

[-- Attachment #5: 2_residency.png --]
[-- Type: image/png, Size: 76961 bytes --]