Linux Power Management development
 help / color / mirror / Atom feed
From: Christian Loehle <christian.loehle@arm.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	Sasha Levin <sashal@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Tomasz Figa <tfiga@chromium.org>,
	stable@vger.kernel.org
Subject: Re: stable: commit "cpuidle: menu: Avoid discarding useful information" causes regressions
Date: Tue, 14 Oct 2025 16:11:09 +0100	[thread overview]
Message-ID: <49cf14a1-b96f-4413-a17e-599bc1c104cd@arm.com> (raw)
In-Reply-To: <nd64xabhbb53bbqoxsjkfvkmlpn5tkdlu3nb5ofwdhyauko35b@qv6in7biupgi>

On 10/14/25 12:55, Sergey Senozhatsky wrote:
> On (25/10/14 11:25), Christian Loehle wrote:
>> On 10/14/25 11:23, Sergey Senozhatsky wrote:
>>> On (25/10/14 10:50), Christian Loehle wrote:
>>>>> Upstream fixup fa3fa55de0d ("cpuidle: governors: menu: Avoid using
>>>>> invalid recent intervals data") doesn't address the problems we are
>>>>> observing.  Revert seems to be bringing performance metrics back to
>>>>> pre-regression levels.
>>>>
>>>> Any details would be much appreciated.
>>>> How do the idle state usages differ with and without
>>>> "cpuidle: menu: Avoid discarding useful information"?
>>>> What do the idle states look like in your platform?
>>>
>>> Sure, I can run tests.  How do I get the numbers/stats
>>> that you are asking for?
>>
>> Ideally just dump
>> cat /sys/devices/system/cpu/cpu*/cpuidle/state*/*
>> before and after the test.
> 
> OK, got some data for you.  The terminology being used here is as follows:
> 
> - 6.1-base
>   is 6.1 stable with a9edb700846 "cpuidle: menu: Avoid discarding useful information"
> 
> - 6.1-base-fixup
>   is 6.1 stable with a9edb700846 and fa3fa55de0d6 "cpuidle: governors:
>   menu: Avoid using invalid recent intervals data" cherry-pick
> 
> - 6.1-revert
>   is 6.1 stable with a9edb700846 reverted (and no fixup commit, obviously)
> 
> Just to show the scale of regression, results of some of the benchmarks:
> 
>   6.1-base:		84.5
>   6.1-base-fixup:	76.5
>   6.1-revert:		59.5
> 
>   (lower is better, 6.1-revert has the same results as previous stable
>   kernels).
This immediately threw me off.
The fixup was written for a specific system which had completely broken
cpuidle. It shouldn't affect any sane system significantly.
I double checked the numbers and your system looks fine, in fact none of
the tests had any rejected cpuidle occurrences. So functionally base and
base-fixup are identical for you. The cpuidle numbers are also reasonably
'in the noise', so just for the future some stats would be helpful on those
scores.

I can see a huge difference between base and revert in terms of cpuidle,
so that's enough for me to take a look, I'll do that now.
(6.1-revert has more C3_ACPI in favor of C1_ACPI.)

(Also I can't send this email without at least recommending teo instead of menu
for your platform / use-cases, if you deemed it unfit I'd love to know what
didn't work for you!)

  reply	other threads:[~2025-10-14 15:11 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14  7:43 stable: commit "cpuidle: menu: Avoid discarding useful information" causes regressions Sergey Senozhatsky
2025-10-14  7:47 ` Greg Kroah-Hartman
2025-10-14  7:54   ` Sergey Senozhatsky
2025-10-14  8:02     ` Greg Kroah-Hartman
2025-10-14 11:08       ` Sergey Senozhatsky
2025-10-14  9:50 ` Christian Loehle
2025-10-14 10:23   ` Sergey Senozhatsky
2025-10-14 10:25     ` Christian Loehle
2025-10-14 11:55       ` Sergey Senozhatsky
2025-10-14 15:11         ` Christian Loehle [this message]
2025-10-14 15:54           ` Rafael J. Wysocki
2025-10-14 17:19             ` Christian Loehle
2025-10-14 17:32               ` Rafael J. Wysocki
2025-10-14 17:50                 ` Rafael J. Wysocki
2025-10-15  1:29             ` Sergey Senozhatsky
2025-10-15  3:41               ` Doug Smythies
2025-10-15  4:50                 ` Sergey Senozhatsky
2025-10-15 14:11                   ` Doug Smythies
2025-10-16  4:59                     ` Sergey Senozhatsky
2025-10-16  9:48                       ` Rafael J. Wysocki
2025-10-16 10:00                         ` Sergey Senozhatsky
2025-10-16 10:05                           ` Rafael J. Wysocki
2025-10-15 11:49                 ` Rafael J. Wysocki
2025-10-15 14:32                   ` Doug Smythies
2025-10-16  9:50                     ` Rafael J. Wysocki
2025-10-15 12:31               ` Rafael J. Wysocki
2025-10-16  4:57                 ` Sergey Senozhatsky
2025-10-15  1:33           ` Sergey Senozhatsky
2025-10-14 13:47     ` Rafael J. Wysocki
2025-10-14 13:56       ` Sergey Senozhatsky
2025-10-14 13:58         ` Christian Loehle
2025-10-14 14:02           ` Rafael J. Wysocki
2025-10-15  1:56             ` Sergey Senozhatsky
2025-10-15 13:08               ` Rafael J. Wysocki
2025-10-16  4:54                 ` Sergey Senozhatsky
2025-10-16  9:47                   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49cf14a1-b96f-4413-a17e-599bc1c104cd@arm.com \
    --to=christian.loehle@arm.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=sashal@kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=stable@vger.kernel.org \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox