Received: by 2002:a05:7412:8598:b0:f9:33c2:5753 with SMTP id n24csp433391rdh; Tue, 19 Dec 2023 03:33:03 -0800 (PST) X-Google-Smtp-Source: AGHT+IHV4i+IRxvaLWlpQmPShVcYz0NYEFQqHN6z0Eb+xAoAWxHYdXi/MgMQKaoylXylTIjia3Bh X-Received: by 2002:a05:6214:242f:b0:67f:434c:3e22 with SMTP id gy15-20020a056214242f00b0067f434c3e22mr5654088qvb.64.1702985582774; Tue, 19 Dec 2023 03:33:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702985582; cv=none; d=google.com; s=arc-20160816; b=ug37PLWLbioI67PCgTnBlUZ+yvi6EaivRlIYGfFQyZG5T3sLjept0aEiWw8tNDObgm D0+dfX42gvLb0d/cK2rCOvJDsHhoITsplGBink5OME/1S2zO7BtJfCg1CU1atPELQNQY iLpq+yBc+Ineu26mpq9vyw3AXKY4hVBzrt3inZ6BRBgku2K7Lzz8aQ9dhYDV0BZwie+0 jcxBl740bJL0FWO8EB2u1LloN9E8L8qTnRsuX4LqUVihDYxsGDbzfHqGArT4XX6B6042 +/E3dc1bZ2q8uNiNrLGcz6BZbl8pa6UjipUnpJ1QNGetJ1G+xUDK4xhUnBjwTZ8VRaY5 qqBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=taJQJvnKughpUb1wkK6mQMBJcEEhQYkY7fDXlMYzd/E=; fh=Z7Bswg0wipPI13DHQPOpxFL/nWO9PLk4OlFtC952Nd8=; b=G//fi2HWznKxs1tYRfGrd69wyZ8h+XOL5cPYiZG8jnrDqpp5y0kKENwhwADiLq4Qp1 iUaFc1pky8SJD6EUR001OwaPA81BWjJKnYtIPn5RFBoL7x1MqEzLeKK+XhW3950SxVd7 eZWAncHT/DEAgkMrxP/be9DdEhDPo7xXD2CZGQi0U3HUO32gZ2m17JLJd+DKbVEfajI6 WdoxU3mn78B+/I0L/hruKNMZLD3VmRpuQ4HRnh72AGOmIHuiKSX1wraovEbt5imszFbx ly/BaKyG9XagAyrvTskWQKE4HK9zrCq/wmvzIFqnqAk2KMQ8t7uo4MXm+uy/aKHGykyz mgTA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-5087-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5087-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id a9-20020a0cb349000000b0067f07abb2b4si8762167qvf.29.2023.12.19.03.33.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Dec 2023 03:33:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-5087-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-5087-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5087-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 864321C216A1 for ; Tue, 19 Dec 2023 11:33:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 912DF15AE6; Tue, 19 Dec 2023 11:32:57 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8B9B4171C3; Tue, 19 Dec 2023 11:32:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1DB601FB; Tue, 19 Dec 2023 03:33:39 -0800 (PST) Received: from [10.57.85.227] (unknown [10.57.85.227]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 974763F738; Tue, 19 Dec 2023 03:32:52 -0800 (PST) Message-ID: <49306168-c0bb-4d22-affe-6129ab35ffd8@arm.com> Date: Tue, 19 Dec 2023 11:33:58 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 08/23] PM: EM: Introduce runtime modifiable table Content-Language: en-US To: Dietmar Eggemann Cc: rui.zhang@intel.com, amit.kucheria@verdurent.com, linux-kernel@vger.kernel.org, amit.kachhap@gmail.com, daniel.lezcano@linaro.org, viresh.kumar@linaro.org, len.brown@intel.com, pavel@ucw.cz, mhiramat@kernel.org, qyousef@layalina.io, wvw@google.com, linux-pm@vger.kernel.org, rafael@kernel.org References: <20231129110853.94344-1-lukasz.luba@arm.com> <20231129110853.94344-9-lukasz.luba@arm.com> From: Lukasz Luba In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/12/23 18:50, Dietmar Eggemann wrote: > On 29/11/2023 12:08, Lukasz Luba wrote: >> The new runtime table can be populated with a new power data to better >> reflect the actual efficiency of the device e.g. CPU. The power can vary >> over time e.g. due to the SoC temperature change. Higher temperature can >> increase power values. For longer running scenarios, such as game or >> camera, when also other devices are used (e.g. GPU, ISP) the CPU power can > > Don't understand this sentence. So CPU power changes with higher > temperature and for longer running scenarios when other devices are > involved? Not getting the 2. part. Total power consists of: 1. dynamic power - related to the freq, voltage^2 and logic capacitance size involved in switching during the computation 2. static power - aka. leakage - depends on voltage and temperature of the silicon. The higher the temperature, the higher the static power. When you heat up the SoC using e.g. GPU, you start seeing on our CPU power plot in time a raising function. Even if your CPU was running constantly the same workload and data for long time, this effect will happen after you add the heat from GPU in the same chip die. IMO this is not the right place to educate people about physics of the chip... Some understating and higher level education would be needed otherwise even the best patch header description won't help. So, I would keep those patch descriptions simple. Beside, I have explained that in a few LPC and OSPM conferences. In the cover letter there are links to them. > >> change. The new EM framework is able to addresses this issue and change >> the EM data at runtime safely. > > Maybe better: > The new EM framework addresses this issue by allowing to change the EM > data at runtime. > Sounds good, I can change that.