Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp7268267ybi; Thu, 1 Aug 2019 05:47:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqx8F1jZUGoJk2Er4sFpWycyH0Uo+v1ZwpSyODlHHt1OL9s2txWV0IQ2JPIbLTbWMAGzeWvq X-Received: by 2002:a63:550d:: with SMTP id j13mr56427173pgb.173.1564663669542; Thu, 01 Aug 2019 05:47:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564663669; cv=none; d=google.com; s=arc-20160816; b=O2OH6cNZ5RQn8irm+nTA0eo6R4YsLQ7NkSyTr8OznSK/mzXSlQt7QT3HO3gHZTk8QL dAf+jx1nnropfkH1X0aKXzxbJ9KEKbsmdYtvVopczKcm/nZhlsNxnoEpOOLYH4jtmPnn eoQZoSIMLmRinxZlx8w/c/tjqgDXb7bmO/XFUGTCgiW5xY26lWuLBgWxUsfndBlGZS6+ i+xvGRta+6YdHV6P3fOdb/fWTkycKMyyBlNzb5m+0hPd3TOEzVW2olHxfi+I88UxtLEu 0TL/HKYlip196e6SHdEdo1DUZzw5CVz2pxN8E9gPXgEfWFk7V/zzsoQkr/aiLd/8bk3F VhpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=M2AxCZJOFptbIDXPTm7H7ryT7SpDUa//UJ+1WeLihHU=; b=My8EQNGoHzwUW3T+SnyQeyZOv/wPnsrNI9u2ewNqo3uODUeDJV5BI5TEZQWljpbOMZ aHuyvTTTPWYjpwUp+HS4KNLdjidXO4PanYh/PZBcHa4d3relam4Um0Vf+bSOONGhhyn9 UY6LXghfzgMVk+zyU3x5OuR9/cwy3PWMinOeqCEkyesPGl/i5FSQ89GbPET4uGNau6vu w7E5MqKiXIOIT9rx9Wy76NRyqr4VkTl8OSLlU8+Gd1A/0nn8ibddfQrU+9AG8i8IOWBI SHvWo6sXpEHERf3ojxb9Fukvtmmnpeae6exwhSm6hhSXQPaYoB5qHoM8JuwfbBKsWAVn 4VWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n6si33674623pgp.424.2019.08.01.05.47.33; Thu, 01 Aug 2019 05:47:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731447AbfHAMqy (ORCPT + 99 others); Thu, 1 Aug 2019 08:46:54 -0400 Received: from foss.arm.com ([217.140.110.172]:35458 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730334AbfHAMqy (ORCPT ); Thu, 1 Aug 2019 08:46:54 -0400 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 44DC51570; Thu, 1 Aug 2019 05:46:53 -0700 (PDT) Received: from queper01-lin.cambridge.arm.com (queper01-lin.cambridge.arm.com [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 41FB93F575; Thu, 1 Aug 2019 05:46:51 -0700 (PDT) From: Quentin Perret To: edubezval@gmail.com, rui.zhang@intel.com, javi.merino@kernel.org, viresh.kumar@linaro.org, amit.kachhap@gmail.com, rjw@rjwysocki.net, catalin.marinas@arm.com, will@kernel.org, daniel.lezcano@linaro.org Cc: dietmar.eggemann@arm.com, ionela.voinescu@arm.com, mka@chromium.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, quentin.perret@arm.com Subject: [PATCH v6 0/3] Make IPA use PM_EM Date: Thu, 1 Aug 2019 13:46:40 +0100 Message-Id: <20190801124643.17112-1-quentin.perret@arm.com> X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Changes in v6 ************* - Added Daniel's and Viresh's Acked-by to all patches Changes in v5: ************** - Changed patch 02 to guard IPA-specific code in cpu_cooling.c with appropriate ifdefery (Daniel) - Rebased on 5.2-rc2 Changes in v4: ************** - Added Viresh's Acked-by to all 3 patches - Improved commit message of patch 3/3 to explain how it has no functional impact on existing users (Eduardo) Changes in v3: ************** - Changed warning message for unordered tables to something more explicit (Viresh) - Changed WARN() into a pr_err() for consistency Changes in v2: ************** - Fixed patch 01/03 to actually enable CONFIG_ENERGY_MODEL - Added "depends on ENERGY_MODEL" to IPA (Daniel) - Added check to bail out if the freq table is unsorted (Viresh) Cover letter: ************* The Intelligent Power Allocator (IPA) thermal governor uses an Energy Model (or EM) of the CPUs to re-distribute the power budget. To do so, it builds a table of tuples where the power values are computed using the 'dynamic-power-coefficient' DT property. All of this is done in and only for the thermal subsystem, and more specifically for CPUs -- the power of other types of devices is obtained differently. Recently, the CPU scheduler has seen the introduction of Energy Aware Scheduling (EAS) patches, which also rely on an EM of the CPUs. This EM, however, is managed by an independent framework, called PM_EM, aimed to be used by all kernel subsystems interested in the power consumed by CPUs, and not only the scheduler. This patch series follows this logic and removes the (now redundant) thermal-specific EM computation code to migrate IPA to use PM_EM instead. Doing so should have no visible functional impact for existing users of IPA since: - during the 5.1 development cycle, a series of patches [1] introduced in PM_OPP some infrastructure (dev_pm_opp_of_register_em()) enabling the registration of EMs in PM_EM using the DT property used by IPA; - the existing upstream cpufreq drivers marked with the 'CPUFREQ_IS_COOLING_DEV' flag all call dev_pm_opp_of_register_em(), which means they all support PM_EM (the only two exceptions are qoriq-cpufreq which doesn't in fact use an EM and scmi-cpufreq which already supports PM_EM without using the PM_OPP infrastructurei because it read power costs directly from firmware); So, migrating IPA to using PM_EM should effectively be just plumbing since for the existing IPA users the PM_EM tables will contain the exact same power values that IPA used to compute on its own until now. The only new dependency is to compile in CONFIG_ENERGY_MODEL. Why is this migration still a good thing ? For three main reasons. 1. it removes redundant code; 2. it introduces an abstraction layer between IPA and the EM computation. PM_EM offers to EAS and IPA (and potentially other clients) standardized EM tables and hides 'how' these tables have been obtained. PM_EM as of now supports power values either coming from the 'dynamic-power-coefficient' DT property or obtained directly from firmware using SCMI. The latter is a new feature for IPA and that comes 'for free' with the migration. This will also be true in the future every time PM_EM gets support for other ways of loading the EM. Moreover, PM_EM is documented and has a debugfs interface which should help adding support for new platforms. 3. it builds a consistent view of the EM of CPUs across kernel subsystems, which is a pre-requisite for any kind of future work aiming at a smarter power allocation using scheduler knowledge about the system for example. [1] https://lore.kernel.org/lkml/20190204110952.16025-1-quentin.perret@arm.com/ Quentin Perret (3): arm64: defconfig: Enable CONFIG_ENERGY_MODEL thermal: cpu_cooling: Make the power-related code depend on IPA thermal: cpu_cooling: Migrate to using the EM framework arch/arm64/configs/defconfig | 1 + drivers/thermal/Kconfig | 1 + drivers/thermal/cpu_cooling.c | 428 ++++++++++++++-------------------- 3 files changed, 178 insertions(+), 252 deletions(-) -- 2.22.0