From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 338F5C4332F for ; Mon, 8 Nov 2021 15:22:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 07C826115A for ; Mon, 8 Nov 2021 15:22:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239080AbhKHPZe (ORCPT ); Mon, 8 Nov 2021 10:25:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238991AbhKHPZ3 (ORCPT ); Mon, 8 Nov 2021 10:25:29 -0500 Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0756C061746 for ; Mon, 8 Nov 2021 07:22:44 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id r26so6816638oiw.5 for ; Mon, 08 Nov 2021 07:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kali.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=g/Jzi4/bsCpORi3XVmLRvQb2/I7DBGZkp7KCpuyf5T4=; b=mwH7FrqfQHnXKY5/RCDBKF2ggnIJcEyODdypMgivJ6eQLdASF6Hwkjw3j5vZk9kv0j EGZnIsoaH/xgkRkINylGmDaZMfPtv07Jq6XIvgIctnr/nRWCHbl2sUHKp/7FYlI+/cF+ P2V07ztnCG2SdGzcI26Gd24RsTx8znOcyNBH/jePoOI5JDZPAXFDs+PfgixGFeCt70o7 98mL+hZWz4UGgFtzGH9I8ZXm9vivkR1XFZcuQ7ZDu/lw3rRiQdKVurksZ7gzDlynnSts alGl5qGDn8/MyKSfW+/q4YxhmzspH2JzpAyaLSkEDyjgPGPt7LtlxCW9Xr9l8UGlYZRc PEhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=g/Jzi4/bsCpORi3XVmLRvQb2/I7DBGZkp7KCpuyf5T4=; b=L/tb9LzUFXHqFxhSYYQlEn4DWaE4xRdPIAMZB/Lk9dpIltQGdD8mIJcfQrfyCUkw/C DBtnFCdL0zdC+UdYi51dLqO21wN5PB025sLEp2fL7mHJB0CzqwK/xD6roCu2rfv3Wjre nG9GqIUDuzdGm6+YFw4IbC4IMuqaNv6gZHCSidYHEdv+qqoXd9OEEGepYpTC3/ZsO7Fi C0pRKez13KBhoIH0UdnLT6eXXm55hsfzZijoHjgW/LTC3ammxqRGE+kkh0R2VphbyaaT diGCWX9m0ySVEl02UgXqW+iedyWe+1RXL7XtQ0dzo+ctDsTTTuqJM3S8FQLhGj+dWuJ4 fKug== X-Gm-Message-State: AOAM533YSVQ4v3ukLHggGVC/NMy1gb6dg7IlMPAMRK9j99AjYUOheYxL ScwPCdDMbLyoEHS5rroomE8rqA== X-Google-Smtp-Source: ABdhPJyA6CRh1gldV9oc+Y86Ziq8FBRBvK1+8E1GkBSCwavEQvBLlT9jJop8RTiuLa1QL65Gd4rWOA== X-Received: by 2002:a05:6808:d53:: with SMTP id w19mr23526832oik.19.1636384964280; Mon, 08 Nov 2021 07:22:44 -0800 (PST) Received: from [192.168.11.48] (cpe-173-173-107-246.satx.res.rr.com. [173.173.107.246]) by smtp.gmail.com with ESMTPSA id e2sm5524291ooh.40.2021.11.08.07.22.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 07:22:43 -0800 (PST) Message-ID: Date: Mon, 8 Nov 2021 09:22:42 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH v3 0/5] Refactor thermal pressure update to avoid code duplication Content-Language: en-US To: Thara Gopinath , Lukasz Luba Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, sudeep.holla@arm.com, will@kernel.org, catalin.marinas@arm.com, linux@armlinux.org.uk, gregkh@linuxfoundation.org, rafael@kernel.org, viresh.kumar@linaro.org, amitk@kernel.org, daniel.lezcano@linaro.org, amit.kachhap@gmail.com, bjorn.andersson@linaro.org, agross@kernel.org References: <20211103161020.26714-1-lukasz.luba@arm.com> <3cba148a-7077-7b6b-f131-dc65045aa348@arm.com> <9d533b6e-a81c-e823-fa6f-61fdea92fa65@kali.org> <74ea027b-b213-42b8-0f7d-275f3b84712e@linaro.org> <74603569-2ff1-999e-9618-79261fdb0ee4@kali.org> <59054c90-c1cd-85bf-406e-579df668d7b4@linaro.org> From: Steev Klimaszewski In-Reply-To: <59054c90-c1cd-85bf-406e-579df668d7b4@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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/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