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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2DA8C19F2A for ; Mon, 1 Aug 2022 12:45:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234862AbiHAMpz (ORCPT ); Mon, 1 Aug 2022 08:45:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234983AbiHAMph (ORCPT ); Mon, 1 Aug 2022 08:45:37 -0400 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3BE8146DA5 for ; Mon, 1 Aug 2022 05:32:54 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id j15so5861109wrr.2 for ; Mon, 01 Aug 2022 05:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=nQEpMirCobOsOWattp713R2f+EJsY/28eyyRhLTxB+E=; b=1MBkA4LqiF8fI0dfhCjDcznALsi41csR8RWo8B2vXIaEqFfOsFRqiHCRFevYzqX8lq tdSDgz5bwsQG79hc3kd4cKyzpweWaDLj5euZHMZ8Q9zdEYqsShIHDKDFttv68frF9K51 8F5YFa7BDVVbtQov0QIiY5bRRnf8WJxlf6auhTUNV9Po0xjI+/zxML6w8lS1N1rA5T3e 2v+pH+AERHtt+02YqoXwVpiKGavKriiDMsM2ynRux63XWQdHX37BU//YBoiIm55BZ0X7 RJq13GSYT2uWpGCrcFYjI2eWBsvW5nfLl9VW3XHlujK3xt5LVd9Ii05ttsfsiRg4YDAN gAtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=nQEpMirCobOsOWattp713R2f+EJsY/28eyyRhLTxB+E=; b=w2UzjIN+5vS0/a/X+8QzOtmyLn0TXXls2sIrtVBogXN+yjQy+O5TCdJ+yFKA/x+Eb3 qLslm3rA+t4dDOl5w9ulV+cTVQAqcmxqK0vx7tHBSv4717J3AOBzoyd7+fsPLL1IetpG urNeasH2/DTlS5T7/LJiz+pcAnlMhrMR4UmbZjFb7fNXM75o6G1zE6BIRPROC8blgA2M OgmgtD2X6v9JLhK/2uOC+JceqOvC7VdqFA7+oN6dmhZmMu0mNQ0R03gAdiC6F3E2WEWJ tQqdNIf4aWppHci5dpD7QP+zboXn2yoYqhavNd95wQk7qcRUtGIiRmZ6c8AOKdMSZ+VB 16Bw== X-Gm-Message-State: ACgBeo2EjwGF6OfAzXLQMJ3B2+ux4zhgva1D1z2xftfPR/8u/At52drt xSaNoXBbBe8OUxiTtgnJvF1XgA== X-Google-Smtp-Source: AA6agR7944sGCx6WI3LpU8LVDq4T/AE2Sxg90GKPb2BHCCrbdYHuOAn49HeQwObUPDO+UkB9PjVvcA== X-Received: by 2002:adf:db4c:0:b0:21e:ef46:af22 with SMTP id f12-20020adfdb4c000000b0021eef46af22mr9755067wrj.424.1659357172791; Mon, 01 Aug 2022 05:32:52 -0700 (PDT) Received: from localhost ([109.180.234.208]) by smtp.gmail.com with ESMTPSA id e13-20020a5d65cd000000b0020fcaba73bcsm11806263wrw.104.2022.08.01.05.32.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Aug 2022 05:32:52 -0700 (PDT) From: Punit Agrawal To: Jeremy Linton Cc: Punit Agrawal , linux-pm@vger.kernel.org, rafael@kernel.org, lenb@kernel.org, viresh.kumar@linaro.org, robert.moore@intel.com, devel@acpica.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/1] ACPI: CPPC: Disable FIE if registers in PCC regions References: <20220728221043.4161903-1-jeremy.linton@arm.com> <20220728221043.4161903-2-jeremy.linton@arm.com> <871qu4krb4.fsf@stealth> Date: Mon, 01 Aug 2022 13:32:51 +0100 In-Reply-To: (Jeremy Linton's message of "Fri, 29 Jul 2022 10:20:46 -0500") Message-ID: <87tu6wjg98.fsf@stealth> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Jeremy Linton writes: > Hi, > > On 7/29/22 07:59, Punit Agrawal wrote: >> Hi Jeremy, >> One comment / query below. >> Jeremy Linton writes: >> >>> PCC regions utilize a mailbox to set/retrieve register values used by >>> the CPPC code. This is fine as long as the operations are >>> infrequent. With the FIE code enabled though the overhead can range >>> from 2-11% of system CPU overhead (ex: as measured by top) on Arm >>> based machines. >>> >>> So, before enabling FIE assure none of the registers used by >>> cppc_get_perf_ctrs() are in the PCC region. Furthermore lets also >>> enable a module parameter which can also disable it at boot or module >>> reload. >>> >>> Signed-off-by: Jeremy Linton >>> --- >>> drivers/acpi/cppc_acpi.c | 41 ++++++++++++++++++++++++++++++++++ >>> drivers/cpufreq/cppc_cpufreq.c | 19 ++++++++++++---- >>> include/acpi/cppc_acpi.h | 5 +++++ >>> 3 files changed, 61 insertions(+), 4 deletions(-) >>> >> [...] >> >>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c >>> index 24eaf0ec344d..ed607e27d6bb 100644 >>> --- a/drivers/cpufreq/cppc_cpufreq.c >>> +++ b/drivers/cpufreq/cppc_cpufreq.c >> [...] >> >>> @@ -229,7 +233,12 @@ static void __init cppc_freq_invariance_init(void) >>> }; >>> int ret; >>> - if (cppc_cpufreq_driver.get == hisi_cppc_cpufreq_get_rate) >>> + if (cppc_perf_ctrs_in_pcc()) { >>> + pr_debug("FIE not enabled on systems with registers in PCC\n"); >> The message should probably be promoted to a pr_info() and exposed >> as >> part of the kernel logs. It is a change in the default behaviour we've >> had until now. The message will provide some hint about why it was >> disabled. >> Thoughts? > > I personally flip flopped between making it pr_info or pr_debug and > settled on debug because no one else was complaining about the > cppc_fie consumption. Which to me, meant that the users of platforms > utilizing PCC regions weren't sensitive to the problem, or weren't yet > running a distro/kernel with it enabled, or any number of other > reasons why the problem wasn't getting more attention. Mostly I > concluded the FIE code hadn't shown up in "enterprise" distros yet.. I too was thinking that likely enterprise users haven't started digging into the performance impact of enabling frequency invariance. > But, yah, if no one is going to complain about the extra messages > pr_info() is a better plan. Thanks! I'll look out for the updated patch. FIE was designed to improve load balancing (and arguably fairness too). Hopefully, the message will aid users in looking more closely and complain to system vendor / upstream if it matters to their workloads.