From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF91D2FE59B for ; Tue, 24 Mar 2026 12:03:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.176 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774353823; cv=pass; b=NUkAnWuYs5SRJ64mjBMfB+fJcxRaOF+sO+Vix2z+jtd2BCchWdygow8Na9GlgNcO+rBOBfP4dGtsI3vdKqzN8RVVmrY5KnIWF4GkfayatZ8p2yOET4v44OsTsGTjPLdb/Q9CmbfEbXy2qsJ/kC/adzomC2ECGRNCH0HeZMi8Mfg= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774353823; c=relaxed/simple; bh=xht2//06apJ5sa0rNqEN/FMso5uXuLZ/poM1328nqeg=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZOVfVpZzNlO18KfAEVX/r94KoRigkC2cX78LvODn/2J3TU3oni+2wf/w23b7/dVYN4qpo5xsWAGpZSmxhN5p2Cr7FgP+YoqBnlmvr5Oh7tNm1jLp8b5IuAbFMtyb5DB1JPbbEzb8WIQr/lm32FWxLfoP3I+YcFudkibwHZeXeDw= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Icbp+Uft; arc=pass smtp.client-ip=209.85.160.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Icbp+Uft" Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-506bcb23a78so40269351cf.3 for ; Tue, 24 Mar 2026 05:03:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774353820; cv=none; d=google.com; s=arc-20240605; b=iDILkB7tBFGoZz5GvMQ+l0oHrMbunRMo3S0+6t8mHzighZcgP1RrjAvM3vQ9WEiyFO UnoJpKZgS5EThk8StoGrCu6EthVZJISg35fdrg8s+sbeHKxOryzPvaRyftv2sI2NHxoI 0i50mK7sJnmMfY0g4LK0mTX4moVbvawpTLi6g3N6mXrXgFSS4s/5UeejMDvo1lfoSwTd pNSKLupzk059Btx6SmhqMODHAIiZ0mIL9BMJxS/j+0NgzBlEWGI0LUBYO6VTg6N8yo1u 72v1DM14lGW0nGCq4SE66VZItpEfHmb/JWF0h0ku91bl71d0InIZ3DUskbllpBsTxQDG ePDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=xuwQvbZgeHRDoxB8YZdL4R9Du7ZDiP5uzm/KqRYSGaA=; fh=dxkeXOb9CEjOYuDVgGbraRZq9YhGDUIC+4E0l+FKpWw=; b=JTSDFSeuG+CVao/6R/iCoNv7bMvLS+POzLnThVzr0R1X8q/2076l826SY0CeTZHvjb sc47LsftaCxPg4VX+IX53aF3Gu9Zr1gvEe47+TgTYy5evk74URdKXHoUTRinA8TyTFqm nPbRXHj1OlJ1+mdckiWJKVL1T9jvqywWI9Wlaly6KwDFpTzYVc4AtDUyxVGEVTwAte7K YJ+LIeeNVh4aSfS7qA6mFXSwYKTG2pPobzSbY7JJ1HEiRKnLXC+THOfgoer4Tp6ZzFmU rCpANJyXDBlIl0AewPtyObkxSrAXMtFUsdK8weLzIn5S6NR1EtxQ8ZUeI500hD3hBi4m 5QCQ==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774353820; x=1774958620; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xuwQvbZgeHRDoxB8YZdL4R9Du7ZDiP5uzm/KqRYSGaA=; b=Icbp+UftoKedEP+N919TqqfnFiINVP4bY80Vi9H3JRrn5VnhYs2juSQ1IkdTLQpGeB Ye0d/7NkIiANR2Yez63mg5NRGD5KdSmy+R1KmbGvEYenpVXOH8ZVEfRKUV8GZIvB+bPI 7Dm7zpIKOd2sBOM8qL1JAhAjV0y+FDlAWA0I+XN/StAxO0qAU+h0quV255q5QPfaxSS3 AMivR8d2O8MdGOsLCSVvfOPnStvsxVcqYmWoKODAa545cHKGcJwBVECEfP17lCWuyxlU 7iBV45yN8Od4Ilk1G9Ihwu2iyqK4PPsYHSw3HoPak3UtKV4cuTtXah/uKRzhondszdc/ W7yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774353820; x=1774958620; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=xuwQvbZgeHRDoxB8YZdL4R9Du7ZDiP5uzm/KqRYSGaA=; b=RF/7on3hc5t3pUW5bgeRCmv89XniaCjGC1n70FH/uRawAPZFu6K4oc8PlKN6Iv0SR3 z1eMtnfQuks7sbYGuCU5RhoONJRWdXAPQJFsPwLoSji8kIJxcbV3xA3BEuK/SdOcsK+9 QogJflEiQ9jQ58w2XpmTljc0CxTGOPXxig7EppA5Fww2apaGY9s/tDJ0Kkc2YB018RE8 Lypg7hfUoDkw/zIarV/F8qk0D4Ozsyd/sJdWCn74hqrzSzne+phjhYCgy71TPKsetCRq 5IE2Uhmxb6RsKDQUoLfl5SoKQCYJ/lBiCapvCn3lEo4ZrJVcfjWlFGEJN8/XoHHY6IbH v4zg== X-Forwarded-Encrypted: i=1; AJvYcCV/iPQdOmRZx8V95F8qhfxvYix2zSdTzpAwyiW3572hKnd0MGNdhjZbwgH/VmCUbKzod1HJUdB+ZLPfWgk=@vger.kernel.org X-Gm-Message-State: AOJu0YxjArX1tCt9ooZrrmC2CsCBH10keJXcysQR6aGw6qtmxlmICFWZ VRPZK+j1hfO6lJXKqLD/fS5hJ4gzcq2yas53gqFVTQmI/akFD/Gw+/O5WoAVsH+uNMr8m+DB9Mp lDsHw+KStzn1p5n6TPIJ2lQolpGBmEz0= X-Gm-Gg: ATEYQzxiz5pS6K5MuhJYGzSpkdhaqIkaVi1wi8/bbKes2aBOci4ZXZcXsZ1oxoi8ZGj rMBQ6UWP779P6o0xY6D7hFex6WxdVXDEahcGbvo33e18A2Pe5xib/yE10tcgH/vsvtmBo24naRz tPNDF0dp72+F+0fNy+tWDnKDxHjIvKEsEnraNTOR6F3V2dYw7baFPEA2jVa8rrDJW0gNBTQAAg/ E64RYAGxNZeeZYDA49QNiRkNaE2Db8zR/d2edAu1ktDNAp1sAl9dSQQcccvpgHaQY0FvIJ/Q+oK TldPql86 X-Received: by 2002:a05:622a:8e15:b0:50b:33c7:5d97 with SMTP id d75a77b69052e-50b374f5c91mr221708461cf.37.1774353820361; Tue, 24 Mar 2026 05:03:40 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260320113148.7308-1-xuewen.yan@unisoc.com> <031562ee-b88f-49b9-8b1e-dbbbe1a508c6@arm.com> <3daf28ca-48c2-477f-ad06-5704b17b880e@arm.com> <2a71d446-3277-4b8e-9b29-b77ebd3a4381@arm.com> <35d472ac-8a58-44c5-a0b1-5e1de8ac6cfc@arm.com> In-Reply-To: <35d472ac-8a58-44c5-a0b1-5e1de8ac6cfc@arm.com> From: Xuewen Yan Date: Tue, 24 Mar 2026 20:03:27 +0800 X-Gm-Features: AaiRm529CioeCv2wAkTMW67vGkmaLJzrBEh645HIXNHAypmBn-ao8gEf8RRAPg4 Message-ID: Subject: Re: [RFC PATCH 1/2] thermal/cpufreq_cooling: remove unused cpu_idx in get_load() To: Lukasz Luba Cc: Viresh Kumar , Xuewen Yan , rui.zhang@intel.com, rafael@kernel.org, linux-pm@vger.kernel.org, amit.kachhap@gmail.com, daniel.lezcano@kernel.org, linux-kernel@vger.kernel.org, ke.wang@unisoc.com, di.shen@unisoc.com, jeson.gao@unisoc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 24, 2026 at 6:45=E2=80=AFPM Lukasz Luba w= rote: > > > > On 3/24/26 02:20, Xuewen Yan wrote: > > On Mon, Mar 23, 2026 at 9:25=E2=80=AFPM Lukasz Luba wrote: > >> > >> > >> > >> On 3/23/26 11:06, Viresh Kumar wrote: > >>> On 23-03-26, 10:52, Lukasz Luba wrote: > >>>>> How is that okay ? What am I missing ? > >>> > >>> I was missing !SMP :) > >>> > >>>> Right, there is a mix of two things. > >>>> The 'i' left but should be removed as well, since > >>>> this is !SMP code with only 1 cpu and i=3D0. > > > > That's also why we sent out patch 1/2; after all, it is always 0 on > > !SMP systems. > > > >>>> > >>>> The whole split which has been made for getting > >>>> the load or utilization from CPU(s) needs to be > >>>> cleaned. The compiled code looks different since > >>>> it knows there is non-SMP config used. > >>> > >>> Right, we are allocating that for num_cpus (which should be 1 CPU > >>> anyway). The entire thing must be cleaned. > >>> > >>>> Do you want to clean that or I should do this? > >>> > >>> It would be helpful if you can do it :) > >>> > >> > >> OK, I will. Thanks for your involvement Viresh! > >> > >> Xuewen please wait with your v2, I will send > >> a redesign of this left code today. > > > > Okay, and Qais's point is also worth considering: do we actually need > > sched_cpu_util()? > > The way I see it, generally speaking, the request_power derived from > > idle_time might be higher than what we get from sched_cpu_util(). > > Take this scenario as an example: > > Consider a CPU running at the lowest frequency with 50% idle time, > > versus one running at the highest frequency with the same 50% idle > > time. > > In this case, using idle_time yields the same load value for both. > > However, sched_cpu_util() would report a lower load when the CPU > > frequency is low. This results in a smaller request_power... > > Right, there are 2 things to consider: > 1. what is the utilization when the CPU still have idle time, e.g. > this 50% that you mentioned > 2. what is the utilization when there is no idle time and CPU > is fully busy (and starts throttling due to heat) > > In this thermal fwk we are mostly in the 2nd case. In that case the > utilization on CPU's runqueue goes to 1024 no mater the CPU's frequency. Haha, indeed. When we debug IPA, we also keep the CPU constantly running with basically no idle time. In this scenario, we tested using both sched_cpu_util() and idle_time, and for thermal control purposes, there was basically no difference (likely because the load was at 100%). Maybe we can cook up a test case where the CPU is overheating despite having some idle time? That way we can compare how the two interfaces perform. > We know which highest frequency was allowed to run and we pick the power > value from EM for it. That's why the estimation is not that bad (apart > from power variation for different flavors of workloads: heavy SIMD vs. > normal integer/load). > > In 1st case scenario we might underestimate the power, but that > is not the thermal stress situation anyway, so the max OPP is > still allowed. > > So far it is hard to find the best power model to use and robust CPU > load mechanisms. Adding more complexity and creating some > over-engineered code in the kernel to maintain might not have sense. > The thermal solutions are solved in the Firmware nowadays since the > kernel won't react that fast for some rapid changes. > > We have to balance the complexity here. > Let's improve the situation a bit. It would be very much appreciated if > you could share information if those changes help your platform > (some older boards might not show any benefit with the new code). > Understood. We appreciate the balance between complexity and accuracy. We could test these changes on our platforms and let you know if we see any improvements in thermal stability or power estimation. Expect an update from us in a few days. Thanks! --- > Regards, > Lukasz >