Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp738582pxp; Fri, 11 Mar 2022 13:50:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJzP2XtoHIr9KyZkZvuDfMg2s5uymJIaYFYiHQT74a1B0oulXDznp2LzmXkT4x7V7wEmFbSj X-Received: by 2002:a63:2004:0:b0:375:ed63:ab4c with SMTP id g4-20020a632004000000b00375ed63ab4cmr10263226pgg.255.1647035406605; Fri, 11 Mar 2022 13:50:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1647035406; cv=none; d=google.com; s=arc-20160816; b=blpJkvudcR+ZFdbJvJhUxHqg0+5RSW9PFEK8pcdiKX1+781oXpW7OTTntgqU0x1osy HLnL/3Ojh5P/RA2yWH4Z74hM90kT0FyP6ULEM0u6jT1DgKhsltoCy5fsEEKSdBnr2y1+ 5hfJhcP7IVFcd5KuiQcVQDZnX/ZNOc8ZD14uRISctMGcWBb4Wajq/dRKXYk+M10WEqYQ ETUnjOSVGrJcs5Jp8eez9Ty+5ZnC+9u7WVX0b3BA5BafKuwpeWElL+QB+vURP0Hg0EBK sxEIhpM6qAg4zSTHsKamaj2juAfQ49AtDZU4aU4gjJX9i9a1LQ1tSm+Ojh9NntAbex7a VUVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=FEtrVBpJ9DBkNlbjxVJR5SHVgIP3hXEvRRRjSXbn5+4=; b=gM8c9YP1SqlO159cvbuTsCAocQ/MLr7aCFY1VN2bxTaU0IoNCfJC4R5w8J1mKlNQAI rs3XFOtd6HYm6+3URDThD8ShBMlYSNVZxEXQvtLNUayiflnHlfDVJ5JNi5QRh0P7kQpZ QK8eMZGIc6iLHMiJsNKoGm7mFoeZPqvNglxE6dyMb1tBFLgTDVSvxSbe+8aIcMJS81Bi zEldadMIbKF+9sruxj/lXX8vNAl8xnq3FoH2wL1bz/6bHRipWn6z39DAwTSwwLjSSrSk s8joZ6f5s/u4uS6pMVR1ebfGux+aNp/pzGoNWXYuF95aME5EY9p5b+fXDwR9cfTVZWqR j69w== 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:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id z9-20020a633309000000b003767f42ab1bsi8577190pgz.338.2022.03.11.13.50.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Mar 2022 13:50:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B2B2325C138; Fri, 11 Mar 2022 13:11:21 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236812AbiCKPz2 (ORCPT + 99 others); Fri, 11 Mar 2022 10:55:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350566AbiCKPyP (ORCPT ); Fri, 11 Mar 2022 10:54:15 -0500 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A58D9ECC57; Fri, 11 Mar 2022 07:53:11 -0800 (PST) Received: by mail-yb1-f175.google.com with SMTP id l2so17819717ybe.8; Fri, 11 Mar 2022 07:53:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FEtrVBpJ9DBkNlbjxVJR5SHVgIP3hXEvRRRjSXbn5+4=; b=N4HcMhA1dOsjtmB6aWz1HIPAMT3s+zwJ0qkHV9mZA1fcHOO9GIi3NRu2iUOsb+OnD8 zq2vkKL6ALVTFFBfmSkizHvGeLyjl79p0MOJGCPi49dh9jPXtcrZZMbkgktEC2zYStAY DJbWsxs1zxTf2EPYATHgu2Zsejynkb8JQ7TurJ2lPnDUBMpTjuC+1saDNvRkMP02xgJs WApW8JgWmk3BrH8IENLUfbKRt2MDpluSW1SuKYPyppP66rYk9xs6Tf6j0lMrS0X/uoH4 HOGSZJR6065KTiZijC9U+uWMqSEiFyllikMmZBDM7JfZ36oX6TP7mAllJpei49SXsndx VguQ== X-Gm-Message-State: AOAM530b6mTLt5TJlIAJRW/WZxMq7cFM5MUskPkYuw5RDh3kSCDUjDGC +45FwwGEIZ5COpjt6g/wjVW+q6Arq/WaJ0dUrLs= X-Received: by 2002:a25:d7c2:0:b0:628:9d06:457b with SMTP id o185-20020a25d7c2000000b006289d06457bmr8462316ybg.137.1647013990912; Fri, 11 Mar 2022 07:53:10 -0800 (PST) MIME-Version: 1.0 References: <20220311081111.159639-1-zhengzucheng@huawei.com> In-Reply-To: <20220311081111.159639-1-zhengzucheng@huawei.com> From: "Rafael J. Wysocki" Date: Fri, 11 Mar 2022 16:52:59 +0100 Message-ID: Subject: Re: [PATCH] cpufreq: fix cpufreq_get() can't get correct CPU frequency To: z00314508 Cc: "Rafael J. Wysocki" , Viresh Kumar , Thomas Gleixner , Len Brown , Linux PM , Linux Kernel Mailing List , Stable Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 On Fri, Mar 11, 2022 at 9:11 AM z00314508 wrote: > > From: Zucheng Zheng > > On some specific platforms, the cpufreq driver does not define > cpufreq_driver.get() routine (eg:x86 intel_pstate driver), as a I guess you mean the cpufreq driver ->get callback. No, intel_pstate doesn't implement it, because it cannot reliably return the current CPU frequency. > result, the cpufreq_get() can't get the correct CPU frequency. No, it can't, if intel_pstate is the driver, but what's the problem? This function is only called in one place in the kernel and not on x8 even. > Modern x86 processors include the hardware needed to accurately > calculate frequency over an interval -- APERF, MPERF and the TSC. You can compute the average frequency over an interval, but ->get is expected to return the actual current frequency at the time call time. > Here we use arch_freq_get_on_cpu() in preference to any driver > driver-specific cpufreq_driver.get() routine to get CPU frequency. > > Fixes: f8475cef9008 ("x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF") No kidding. > Signed-off-by: Zucheng Zheng > --- > drivers/cpufreq/cpufreq.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 80f535cc8a75..d777257b4454 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -1806,10 +1806,14 @@ unsigned int cpufreq_get(unsigned int cpu) > { > struct cpufreq_policy *policy = cpufreq_cpu_get(cpu); > unsigned int ret_freq = 0; > + unsigned int freq; > > if (policy) { > down_read(&policy->rwsem); > - if (cpufreq_driver->get) > + freq = arch_freq_get_on_cpu(policy->cpu); > + if (freq) > + ret_freq = freq; > + else if (cpufreq_driver->get) Again, what problem exactly does this address? > ret_freq = __cpufreq_get(policy); > up_read(&policy->rwsem); > > --