linux-kernel - Re: [PATCH v1 0/3] thermal/debugfs: Fix and clean up trip point statistics updates

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: <3a8f1978-c5df-40d6-91ca-276431bb01e1@arm.com>
Date: Mon, 22 Apr 2024 12:37:18 +0100
From: Lukasz Luba <lukasz.luba@....com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: LKML <linux-kernel@...r.kernel.org>, Linux PM <linux-pm@...r.kernel.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>
Subject: Re: [PATCH v1 0/3] thermal/debugfs: Fix and clean up trip point
 statistics updates

Hi Rafael,

On 4/17/24 14:07, Rafael J. Wysocki wrote:
> Hi Everyone,
> 
> The first patch in this series addresses the problem of updating trip
> point statistics prematurely for trip points that have just been
> crossed on the way down (please see the patch changelog for details).
> 
> The way it does that renders the following cleanup patch inapplicable:
> 
> https://lore.kernel.org/linux-pm/2321994.ElGaqSPkdT@kreacher/
> 
> The remaining two patches in the series are cleanups on top of the
> first one.
> 
> This series is based on an older patch series posted last week:
> 
> https://lore.kernel.org/linux-pm/13515747.uLZWGnKmhe@kreacher/
> 
> but it can be trivially rebased on top of the current linux-next.
> 
> Thanks!
> 
> 
> 

I've checked this patch patch set on top of your bleeding-edge
which has thermal re-work as well. The patch set looks good
and works properly.

Although, I have found some issue in this debug info files and
I'm not sure if this is expected or not. If not I can address this
and send some small fix for it.

When I read the cooling device residency statistics, I don't
get updates for the first time the state is used. It can only
be counted when that state was known and finished it's usage.

IMO it is not the right behavior, isn't it?

Experiment:
My trip points are 70degC and 75degC and I'm setting emulated
temperature to cross them and get cooling states 1 then 0.
As you can see the statistics counter only starts showing value after
after trip crossing down.
------------------------------------8<-----------------------------------

root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
root@arm:~#
root@arm:~#
root@arm:~# echo 71000 > /sys/class/thermal/thermal_zone0/emul_temp 

root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
root@arm:~# echo 76000 > /sys/class/thermal/thermal_zone0/emul_temp 

root@arm:~#
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
0       518197
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
0       518197
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
0       518197
root@arm:~# echo 71000 > /sys/class/thermal/thermal_zone0/emul_temp 

root@arm:~#
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
0       520066
1       17567
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
0       522653
1       17567
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
0       526151
1       17567
root@arm:~# echo 66000 > /sys/class/thermal/thermal_zone0/emul_temp 

root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
0       537366
1       17567
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
0       544936
1       17567
root@arm:~# cat 
/sys/kernel/debug/thermal/cooling_devices/0/time_in_state_ms
State   Residency
0       556694
1       17567
root@arm:~#

------------------------------->8----------------------------------------

Please let me know what do you think about that behavior.

Regards,
Lukasz