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: <7bd9aa9f-1d1f-ea12-57ba-adf5d69cbbfb@arm.com>
Date:   Mon, 8 Nov 2021 10:44:16 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Steev Klimaszewski <steev@...i.org>
Cc:     Thara Gopinath <thara.gopinath@...aro.org>,
        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



On 11/5/21 10:46 PM, Steev Klimaszewski wrote:
> 
>> [snip]
>> Hi,
>>
>> So IIUC the below logs correctly, you are never hitting boost 
>> frequency (with or without this patch series). Is that correct ?
>>
>> w.r.t temperature , how are you measuring it? Do you have LMh enabled 
>> or are you using tsens to mitigate cpu temperature ?
> 
> 
> Hi,
> 
> I was wrong - it does indeed go boost with the patchset applied, it's 
> just that it doesn't boost up to 2.96GHz very often at all. As noted by 
> the 0.03% when i ran it while compiling zellij; I reapplied the patches 
> (and the 6th patch from Lukasz's email) and after boot, 2.96GHz was 
> showing at 0.39%.
> 
> Most tools that read the cpu frequency don't really seem to be well 
> suited for big.LITTLE, and seem to throw an average of the speed, so 
> cpufreq-info was the best I have.  We're apparently supposed to be using 
> cpupower these days, but it doesn't seem to know anything about arm64 
> devices.
> 
> Temperature wise, I'm just getting from the sensors, and I am using LMh.
> 
> Now, I have to admit, while I've thrown a patch here or there, I'm not 
> exactly a kernel developer, just enough knowledge to be somewhat 
> dangerous and know how to backport things.  In my mind, and my line of 
> thinking, I would expect with boost enabled, that the cpu would boost up 
> to that as often as possible, not require a specific workload to 
> actually hit it.  But then again, I would expect multiple compilation 
> jobs to be one of the workloads that would?
> 
> So I think, the part about never hitting 2.96GHz can be dismissed, and 
> was simply my lack of knowledge about the cpufreq-info tool's averages. 
> It does seem however to rarely ever hit 2.96GHz and I would actually 
> expect it to hit it far more often.
> 

Thank you for the logs and re-testing it with the debug changes.
That's valuable information. I'll work on it today.

Regarding the 'boost' frequency, as you observed, it's hard to
measure it properly. Normally when you use the frequency governor
'schedutil' (which is your case), you need a high utilization workload
to request highest frequency. The task scheduler does this calculation
and then asks for the frequency.
I'll spend more time trying to understand how this Qcom driver and HW
handles it. The patch set itself should not block it.

I'll get back to you soon.

Regards,
Lukasz