linux-kernel - Re: cpufreq/thermal regression in 6.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6759ce9f-281d-4fcd-bb4c-b784a1cc5f6e@oldschoolsolutions.biz>
Date: Fri, 21 Jun 2024 17:46:06 +0200
From: Jens Glathe <jens.glathe@...schoolsolutions.biz>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Johan Hovold <johan@...nel.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
 Daniel Lezcano <daniel.lezcano@...aro.org>,
 Viresh Kumar <viresh.kumar@...aro.org>, Zhang Rui <rui.zhang@...el.com>,
 Lukasz Luba <lukasz.luba@....com>, Steev Klimaszewski <steev@...i.org>,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 regressions@...ts.linux.dev
Subject: Re: cpufreq/thermal regression in 6.10

Hi there,

unfortunately I experienced the issue with the fix applied. I had to
revert this and  the original commit to get back to normal behaviour. My
system (also Lenovo Thinkpad X13s) uses the schedutil governor, the
behaviour is as described from Steev and Johan. The full throttling
happened during a package build and left the performance cores at 940800.

Cheers

Jens

On 6/11/24 12:54, Rafael J. Wysocki wrote:
> On Mon, Jun 10, 2024 at 1:17 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>> Hi,
>>
>> Thanks for the report.
>>
>> On Sun, Jun 9, 2024 at 9:53 AM Johan Hovold <johan@...nel.org> wrote:
>>> Hi,
>>>
>>> Steev reported to me off-list that the CPU frequency of the big cores on
>>> the Lenovo ThinkPad X13s sometimes appears to get stuck at a low
>>> frequency with 6.10-rc2.
>>>
>>> I just confirmed that once the cores are fully throttled (using the
>>> stepwise thermal governor) due to the skin temperature reaching the
>>> first trip point, scaling_max_freq gets stuck at the next OPP:
>>>
>>>          cpu4/cpufreq/scaling_max_freq:940800
>>>          cpu5/cpufreq/scaling_max_freq:940800
>>>          cpu6/cpufreq/scaling_max_freq:940800
>>>          cpu7/cpufreq/scaling_max_freq:940800
>>>
>>> when the temperature drops again.
>> So apparently something fails to update its frequency QoS request.
>>
>> Would it be possible to provoke this with thermal debug enabled
>> (CONFIG_THERMAL_DEBUGFS set) and see what's there in
>> /sys/kernel/debug/thermal/?
>>
>>> This obviously leads to a massive performance drop and could possibly
>>> also be related to reports like this one:
>>>
>>>          https://lore.kernel.org/all/CAHk-=wjwFGQZcDinK=BkEaA8FSyVg5NaUe0BobxowxeZ5PvetA@mail.gmail.com/
>>>
>>> I assume the regression may have been introduced by all the thermal work
>>> that went into 6.10-rc1, but I don't have time to try to track this down
>>> myself right now (and will be away from keyboard most of next week).
>>>
>>> I've confirmed that 6.9 works as expected.
>> Well, I'd need to ask someone else affected by this, then.
> If this is the step-wise governor, the problem might have been
> introduced by commit
>
> 042a3d80f118 thermal: core: Move passive polling management to the core
>
> which removed passive polling count updates from that governor, so if
> the thermal zone in question has passive polling only and no regular
> polling, temperature updates may stop coming before the governor drops
> the cooling device states to the "no target" level.
>
> So please test the attached partial revert of the above commit when you can.