linux-kernel - Re: [PATCH v3 0/5] Refactor thermal pressure update to avoid code duplication

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: <eac00041-a1b8-0780-931d-52249d538800@kali.org>
Date:   Mon, 8 Nov 2021 09:22:42 -0600
From:   Steev Klimaszewski <steev@...i.org>
To:     Thara Gopinath <thara.gopinath@...aro.org>,
        Lukasz Luba <lukasz.luba@....com>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, sudeep.holla@....com,
        will@...nel.org, catalin.marinas@....com, linux@...linux.org.uk,
        gregkh@...uxfoundation.org, rafael@...nel.org,
        viresh.kumar@...aro.org, amitk@...nel.org,
        daniel.lezcano@...aro.org, amit.kachhap@...il.com,
        bjorn.andersson@...aro.org, agross@...nel.org
Subject: Re: [PATCH v3 0/5] Refactor thermal pressure update to avoid code
 duplication


> Hi Steev,
>
> So this depends on the cpufreq governor you are using. By-default arm 
> systems have sched-util governor enabled. This means you will scale up 
> to boost depending on cpu load and not always. If you want to ensure 
> you are always hitting boost frequency, you should enable performance 
> governor for cpufreq and try.
>
> Also since the defconfig has by default CPU_FREQ_STAT enabled, you 
> should be able to get statistics out of cpufreq to see the time spent 
> by a cpu in each frequency. I think cpufreq-info -s should give you 
> this info. If not, you can explicitly get it for each cpu from
>
> cat /sys/devices/system/cpu/cpu<X>/cpufreq/stats/time_in_state
>
> Regarding temperature, if you have applied all the patches in the 
> sdm845 LMh series and have LMh enabled, cpu throttling starts around 
> 95 degree C.
>
Hi Thara,

Indeed, I ended up finding the time_in_state when I was doing more 
digging after my last mail.  I do have the sdm845 LMh series and LMh 
enabled, however I don't think I've ever seen my system go above 90C here.

So a quick look, and... we are simply almost never getting the 2.95GHz 
at all, regardless of workload.  I saw Lukasz response as well about the 
math possibly being wrong, but I haven't had a chance.

Regarding the time in state - I went with policy4 instead of per cpu 
(for brevity sake) and it's here:

c630:~$ cat /sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
825600 225037
902400 92
979200 205
1056000 96
1209600 902
1286400 386
1363200 396
1459200 217
1536000 101
1612800 75
1689600 95
1766400 130
1843200 255
1920000 318
1996800 92
2092800 87
2169600 66
2246400 60
2323200 58
2400000 54
2476800 47
2553600 50
2649600 69
2745600 58
2841600 54619
2956800 5

So we spend *very* little time in 2.96GHz and this is after almost 14 
hours of uptime on the C630.  By comparison, on a Pinebook Pro where 
I've added in 2GHz as a boost frequency :

pinebook-pro:~$ cat 
/sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
408000 16084466
600000 27212
816000 32487
1008000 11331
1200000 13268
1416000 75078
1608000 18392
1800000 207266
2016000 648612

With the Pinebook Pro, which doesn't even come close to getting to 95C, 
we spend a lot more time in 2GHz.

-- steev