[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0jMoEVUaYYPx6EtHFxsg6TF-QtDWJGrasGK7C2C+JxOFw@mail.gmail.com>
Date: Sat, 18 Oct 2025 13:46:32 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Christian Loehle <christian.loehle@....com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Linux PM <linux-pm@...r.kernel.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>, LKML <linux-kernel@...r.kernel.org>,
Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>, Tomasz Figa <tfiga@...omium.org>,
Doug Smythies <dsmythies@...us.net>
Subject: Re: [PATCH v1] cpuidle: governors: menu: Predict longer idle time
when in doubt
On Fri, Oct 17, 2025 at 8:37 PM Christian Loehle
<christian.loehle@....com> wrote:
>
> On 10/17/25 10:39, Rafael J. Wysocki wrote:
> > On Fri, Oct 17, 2025 at 10:22 AM Christian Loehle
> > <christian.loehle@....com> wrote:
> >>
> >> On 10/16/25 17:25, Rafael J. Wysocki wrote:
> >>> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >>>
> >>> It is reported that commit 85975daeaa4d ("cpuidle: menu: Avoid discarding
> >>> useful information") led to a performance regression on Intel Jasper Lake
> >>> systems because it reduced the time spent by CPUs in idle state C7 which
> >>> is correlated to the maximum frequency the CPUs can get to because of an
> >>> average running power limit [1].
> >>> [snip]
> >> [snip]
> >> Anyway, the patch makes sense, let me run some tests and get back.
> >
> > Thanks!
>
> Unfortunately this patch regresses my tests about as much as a revert of
> 85975daeaa4d would.
> (menu-1 is $SUBJECT, menu-m current mainline, menu-r mainline with
> 85975daeaa4d reverted):
>
>
> device gov iter iops idles idle_misses idle_miss_ratio belows aboves
> mmcblk1 menu-1 0 1523 402522 119988 0.298 98552 21436
> mmcblk1 menu-1 1 1481 395766 118596 0.300 97640 20956
> mmcblk1 menu-1 2 1503 396560 117876 0.297 97506 20370
> mmcblk1 menu-m 0 2355 703732 22275 0.032 2628 19647
> mmcblk1 menu-m 1 2359 637522 24815 0.039 4075 20740
> mmcblk1 menu-m 2 2356 706980 23836 0.034 3208 20628
> mmcblk1 menu-r 0 1490 388180 118294 0.305 97871 20423
> mmcblk1 menu-r 1 1498 393402 119984 0.305 99187 20797
> mmcblk1 menu-r 2 1462 388597 119504 0.308 98640 20864
> mmcblk2 menu-1 0 3303 503938 170251 0.338 150276 19975
> mmcblk2 menu-1 1 3310 480508 132132 0.275 114398 17734
> mmcblk2 menu-1 2 3554 466884 113659 0.243 95841 17818
> mmcblk2 menu-m 0 5746 706262 24618 0.035 3802 20816
> mmcblk2 menu-m 1 5741 727174 24152 0.033 3737 20415
> mmcblk2 menu-m 2 5777 836940 12424 0.015 335 12089
> mmcblk2 menu-r 0 3241 463112 133052 0.287 114616 18436
> mmcblk2 menu-r 1 3551 422006 100494 0.238 82425 18069
> mmcblk2 menu-r 2 3523 508542 140085 0.275 122880 17205
> nvme0n1 menu-1 0 5407 436834 74314 0.170 54133 20181
> nvme0n1 menu-1 1 5763 459510 72673 0.158 51530 21143
> nvme0n1 menu-1 2 6266 489570 78651 0.161 58609 20042
> nvme0n1 menu-m 0 10786 767740 23840 0.031 2855 20985
> nvme0n1 menu-m 1 10586 757540 23612 0.031 2933 20679
> nvme0n1 menu-m 2 11805 834012 23528 0.028 2768 20760
> nvme0n1 menu-r 0 5323 431906 77426 0.179 56166 21260
> nvme0n1 menu-r 1 5484 438142 76033 0.174 55956 20077
> nvme0n1 menu-r 2 5353 428826 77024 0.180 57016 20008
> sda menu-1 0 972 444116 149643 0.337 129023 20620
> sda menu-1 1 954 557068 176479 0.317 159092 17387
> sda menu-1 2 878 540360 196405 0.363 176792 19613
> sda menu-m 0 1634 1017918 29614 0.029 8587 21027
> sda menu-m 1 1622 878140 25323 0.029 8238 17085
> sda menu-m 2 1632 1027167 28798 0.028 8428 20370
> sda menu-r 0 918 531112 188314 0.355 168375 19939
> sda menu-r 1 924 521378 185727 0.356 165327 20400
> sda menu-r 2 880 529146 196391 0.371 176908 19483
> nullb0 menu-1 0 101419 88988 23923 0.269 3080 20843
> nullb0 menu-1 1 101610 88484 23678 0.268 2821 20857
> nullb0 menu-1 2 101369 89336 23711 0.265 2795 20916
> nullb0 menu-m 0 101696 88698 23860 0.269 2910 20950
> nullb0 menu-m 1 101103 88120 23294 0.264 3295 19999
> nullb0 menu-m 2 101880 86676 22730 0.262 2709 20021
> nullb0 menu-r 0 101856 87742 23493 0.268 3204 20289
> nullb0 menu-r 1 101514 89070 23653 0.266 2848 20805
> nullb0 menu-r 2 101754 86318 23163 0.268 3229 19934
> mtdblock3 menu-1 0 163 350284 115149 0.329 97166 17983
> mtdblock3 menu-1 1 179 315948 99038 0.313 78243 20795
> mtdblock3 menu-1 2 134 481584 160754 0.334 144150 16604
> mtdblock3 menu-m 0 215 410034 70261 0.171 55445 14816
> mtdblock3 menu-m 1 205 570150 109273 0.192 90189 19084
> mtdblock3 menu-m 2 252 866616 23492 0.027 9717 13775
> mtdblock3 menu-r 0 132 467365 161835 0.346 144056 17779
> mtdblock3 menu-r 1 164 348682 117704 0.338 97859 19845
> mtdblock3 menu-r 2 132 483300 165179 0.342 147164 18015
Well, this means that in the majority of cases the maximum sample idle
time is so large that UINT_MAX may as well be returned instead.
The possible correlation between idle power and the max OPP a CPU can
get to has not been taken into account in cpuidle directly so far, but
it clearly isn't true that using shallow idle states more often always
improves performance. It may hurt performance too.
Actually, this possible correlation appears to have a broader impact,
as it may affect CAS and EAS at least in principle, so it may be
advisable to allocate some time for discussing it during upcoming
conferences.
At this point I'm inclined to revert commit 85975daeaa4d because
anything else would be clearly artificial and likely ineffective at
least in some cases.
The systems that enjoyed better performance after that commit can
switch over to teo and continue to enjoy it and everybody else still
using menu should be able to continue to do so.
Powered by blists - more mailing lists