Subject: Re: stable: commit "cpuidle: menu: Avoid discarding useful information" causes regressions

From: "Rafael J. Wysocki" <[email-masked]>
Date: Thu, 16 Oct 2025 11:47:10 +0200

On Thu, Oct 16, 2025 at 6:54 AM Sergey Senozhatsky
<[email-masked]> wrote:
>
> On (25/10/15 15:08), Rafael J. Wysocki wrote:
> > On Wed, Oct 15, 2025 at 3:56 AM Sergey Senozhatsky
> > <[email-masked]> wrote:
> > >
> > > On (25/10/14 16:02), Rafael J. Wysocki wrote:
> > > > > >> Would it be possible to check if the mainline has this issue?  That
> > > > > >> is, compare the benchmark results on unmodified 6.17 (say) and on 6.17
> > > > > >> with commit 85975daeaa4 reverted?
> > > > > >
> > > > > > I don't think mainline kernel can run on those devices (due to
> > > > > > a bunch of downstream patches).  Best bet is 6.12, I guess.
> > > > >
> > > > > Depending on what Rafael is expecting here you might just get
> > > > > away with copying menu.c from mainline, the interactions to other
> > > > > subsystems are limited fortunately.
> > > >
> > > > Yeah, that'd be sufficiently close.
> > >
> > > Test results for menu.c from linux-next are within regressed range: 78.5
> >
> > So please check if the attached patch makes any difference.
>
> From what I can tell the patch fixes it!

Well, that's something.

As far as I'm concerned, this change can be made.

>From a purely theoretical standpoint, arguments can be made for doing
it as well as for the current code and none of them is definitely
preferable.

The current approach was chosen because it led to lower latency which
should result in better performance, but after the patch the code is
closer to what was done before.

Let me submit it officially and we'll see what people will have to say.

---

From: "Rafael J. Wysocki" <[email-masked]>
Date: Thu, 16 Oct 2025 11:48:46 +0200

On Thu, Oct 16, 2025 at 6:59 AM Sergey Senozhatsky
<[email-masked]> wrote:
>
> On (25/10/15 07:11), Doug Smythies wrote:
> > >> What thermal limiting methods are being used? Is idle injection being used? Or CPU frequency limiting or both.
> > >
> > > How do I find out?
> >
> > From the turbostat data you do not appear to be using the TCC offset method. This line:
> >
> > cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x0f690080 (105 C)
> >
> > whereas on my test computer, using the TCC offset method, shows:
> >
> >  cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x14641422 (80 C) (100 default - 20 offset)
> >
> > To check if thermal is being used do:
> >
> > systemctl status thermal
>
> chromeos doesn't use systemd.
> A quick ps grep doesn't show any thermal-related processes.

All right, let's see what RAPL on that system has to say.

Please send the output of "grep .
/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_*"

---

From: "Rafael J. Wysocki" <[email-masked]>
Date: Thu, 16 Oct 2025 11:50:23 +0200

On Wed, Oct 15, 2025 at 4:32 PM Doug Smythies <[email-masked]> wrote:
>
> On 2025.10.14 04:50 Rafael J. Wysocki wrote:
> > On Wed, Oct 15, 2025 at 5:41 AM Doug Smythies <[email-masked]> wrote:
> >>
> >> On 2025.10.14 18:30 Sergey Senozhatsky wrote:
> >>> On (25/10/14 17:54), Rafael J. Wysocki wrote:
> >>>> Sergey, can you please run the workload under turbostat on the base
> >>>> 6.1.y and on 6.1.y with the problematic commit reverted and send the
> >>>> turbostat output from both runs (note: turbostat needs to be run as
> >>>> root)?
> >>>
> >>> Please find attached the turbostat logs for both cases.
> >>
> >> The turbostat data suggests that power limit throttling is involved.
> >
> > Why do you think so?
>
> I observed sustained processor package powers over the PL1 limit of 6 watts,
> combined with increased busy % while at the same time power and CPU frequency going down.
> I admit the time constant of 28 seconds only seems to be exceeded once.

I see, thanks!

> Since I seem to be unable to function without making a graph, some are attached,
> including Idle state usage, which might be useful for your other email.

Thanks for the graphs, they are useful.

> (The graphs are poorly labelled and such.)

No worries.

---

From: Sergey Senozhatsky <[email-masked]>
Date: Thu, 16 Oct 2025 19:00:36 +0900

> /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_*"

/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_max_power_uw:6000000
/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_name:long_term
/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw:6000000
/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_time_window_us:27983872
/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_1_max_power_uw:0
/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_1_name:short_term
/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_1_power_limit_uw:12000000
/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_1_time_window_us:976

---

From: "Rafael J. Wysocki" <[email-masked]>
Date: Thu, 16 Oct 2025 12:05:58 +0200

> /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_1_time_window_us:976

This looks reasonable, so I'd rather not recommend playing with it.

---

From: Sergey Senozhatsky <[email-masked]>
Date: Thu, 16 Oct 2025 13:54:34 +0900

---

From: Sergey Senozhatsky <[email-masked]>
Date: Thu, 16 Oct 2025 13:57:24 +0900

On (25/10/15 14:31), Rafael J. Wysocki wrote:
> Thanks!
> First off, the CPUiD information reported by turbostat indicates that
> the system is a Jasper Lake.  Is this correct?

Correct.  That particular board is powered by Jasper Lake.

[..]
> Something like this may be induced by RAPL power limits, presumably PL1.
> 
> Do you use thermald?

I don't think so.  chromeos doesn't use systemd.

---

From: Sergey Senozhatsky <[email-masked]>
Date: Thu, 16 Oct 2025 13:59:02 +0900

---

From: "Doug Smythies" <[email-masked]>
Date: Wed, 15 Oct 2025 07:11:41 -0700

On 2025.10.14 21:50 Sergey Senozhatsky wrote:
> On (25/10/14 20:41), Doug Smythies wrote:

systemctl status thermal

Example:

doug@s19:~/idle/teo/menu2$ systemctl status thermald