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 0E1E1C00144 for ; Mon, 1 Aug 2022 12:45:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234871AbiHAMpz (ORCPT ); Mon, 1 Aug 2022 08:45:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234985AbiHAMph (ORCPT ); Mon, 1 Aug 2022 08:45:37 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C75446DA8 for ; Mon, 1 Aug 2022 05:32:54 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id l4so13946943wrm.13 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=g6SQpoyBtE27OEN1F5VxwMxo9nOfYXn6/UgPvVOB4HVdQJLQMrWIEBj/MJoOiFIDTL 8Ndl1LKWcTxCNzsM3ZERznU1PBLnmYtCF4GKrGG0QgikJc31e0/OnroK5NnT182YJ3TY 2Tl4bWi/2WElJ+6/P00i/ZXH+lz9YYRuyLSf/nzTot2hmEVNsdJP54lWFkOYVWmxEaKZ xdwaRdqfSBcBpTW08qndyoXeIcRQUqggMkyJb7rdULqo4+gWtpAyD663YlNso7WM+BUS 8cbeksFZwESikLWTQgZsrC3+9f2+grOR9EPGZLtbB+aohxPV7qSWLxwqx+8vY47/SisZ PXGQ== X-Gm-Message-State: ACgBeo1Q0i2vPazr5VACYQsUn8FrIiF65r7zuEyiwzmGDnNQ8ZBtgPXp 6OaXpzBWKvMBF7B0QbQziW9Ycg== 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-acpi@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.