Received: by 2002:a05:6359:322:b0:b3:69d0:12d8 with SMTP id ef34csp119668rwb; Wed, 10 Aug 2022 05:55:28 -0700 (PDT) X-Google-Smtp-Source: AA6agR6BkigmRQxGiohdjmwNw/UUcREgVaf/q9FogC9mWqgFZ3SrRMg64FU2Znhb9MKBhnn3xX4Q X-Received: by 2002:a17:906:84e1:b0:732:1ea0:8b43 with SMTP id zp1-20020a17090684e100b007321ea08b43mr6038424ejb.343.1660136127905; Wed, 10 Aug 2022 05:55:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660136127; cv=none; d=google.com; s=arc-20160816; b=v/v1u9ABHGCQ5j/yta3eO/9Dc85uIbyyJL7RNBLYlJaYPPiwa/ntpPLfOtb6aXGFwh CXK9jJlewKBG6gxubiEfvqejCj+F3ZbkShCgSGyx0fIHCYIfSI7w+jSmJu+OVsada0zi 9F69wDzHZ92O5qLlzdYM3J7rP/TxfljfvlA7vFEJBAyqnESBA4iEPANMKj4VxtvSWsY/ z3FsBrI52H7+5Uc5C/krG0Lfo9sXDco1Cea4AMMLO1ijUa4GOx6QX8hLYnmBrUGuJWqE AxnmfpXiDGnMbTO2i2LTihK7dIniAe53Z6KJ/Nui4V669g1YaOCaeYyBYktkI0XSG3ib FspQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=oo4WoW7gD0YT3BBkCwxRojlUrPGtonMJX78vLrkV5Zg=; b=QmxNCuiOZk/Hb77XVPljO+5RheLhvwn4t+rwEu7v3SOf182omTJlfGoU7fA8VXzutj dC9b467Of2eMvNPHktqJs0vn62mdV1yYH+qZ9xFq6kWxr3hFr9I2NZXA99RCzxCitoiI ii7SHwaL8rCQF1UAaAp8nAbZ49zacBEDC0+fwxcb0fWfQaZ/qjVu1Zq7Se2tce9y1zyw dpb5UbUSOla985MdqkeYoBdSvwxsFnKGoiWAofee5zFMty8+RsXRTph38jhmJUEwNwoT Pp/fkKiM3026eY+yHjWjqzgRSPAtv9jlMhoV0nccqYbxwgBJo9hkrEWqmZtXFNrDjKC6 ivxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id he19-20020a1709073d9300b007305b582b36si5432584ejc.469.2022.08.10.05.55.02; Wed, 10 Aug 2022 05:55:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230006AbiHJM3Q (ORCPT + 99 others); Wed, 10 Aug 2022 08:29:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232241AbiHJM3N (ORCPT ); Wed, 10 Aug 2022 08:29:13 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A57987437F; Wed, 10 Aug 2022 05:29:12 -0700 (PDT) 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 08CDE1FB; Wed, 10 Aug 2022 05:29:13 -0700 (PDT) Received: from [10.57.13.63] (unknown [10.57.13.63]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3EFD23F5A1; Wed, 10 Aug 2022 05:29:10 -0700 (PDT) Message-ID: <3a5e7abd-9361-11ba-978d-8e8bae00ea31@arm.com> Date: Wed, 10 Aug 2022 13:29:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v2 1/1] ACPI: CPPC: Disable FIE if registers in PCC regions Content-Language: en-US To: Jeremy Linton Cc: 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, linux-pm@vger.kernel.org, vschneid@redhat.com, Ionela Voinescu , Dietmar Eggemann References: <20220728221043.4161903-1-jeremy.linton@arm.com> <20220728221043.4161903-2-jeremy.linton@arm.com> From: Lukasz Luba In-Reply-To: <20220728221043.4161903-2-jeremy.linton@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jeremy, +CC Valentin since he might be interested in this finding +CC Ionela, Dietmar I have a few comments for this patch. On 7/28/22 23:10, Jeremy Linton wrote: > 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(-) 1. You assume that all platforms would have this big overhead when they have the PCC regions for this purpose. Do we know which version of HW mailbox have been implemented and used that have this 2-11% overhead in a platform? Do also more recent MHU have such issues, so we could block them by default (like in your code)? 2. I would prefer to simply change the default Kconfig value to 'n' for the ACPI_CPPC_CPUFREQ_FIE, instead of creating a runtime check code which disables it. We have probably introduce this overhead for older platforms with this commit: commit 4c38f2df71c8e33c0b64865992d693f5022eeaad Author: Viresh Kumar Date: Tue Jun 23 15:49:40 2020 +0530 cpufreq: CPPC: Add support for frequency invariance If the test server with this config enabled performs well in the stress-tests, then on production server the config may be set to 'y' (or 'm' and loaded). I would vote to not add extra code, which then after a while might be decided to bw extended because actually some HW is actually capable (so we could check in runtime and enable it). IMO this create an additional complexity in our diverse configuration/tunnable space in our code. When we don't compile-in this, we should fallback to old-style FIE, which has been used on these old platforms. BTW (I have to leave it here) the first-class solution for those servers is to implement AMU counters, so the overhead to retrieve this info is really low. Regards, Lukasz