Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4089751pxv; Mon, 28 Jun 2021 21:53:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKBEcGcQsnMQkeAwzFa1h2AN6ycxFzK0X2z9R9UDPbHYaeQSKomoS4AMahc3rcXEFZ/BEk X-Received: by 2002:a17:906:b7cb:: with SMTP id fy11mr27757416ejb.189.1624942438322; Mon, 28 Jun 2021 21:53:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624942438; cv=none; d=google.com; s=arc-20160816; b=BQvQ5MtdbuP4tw5w3kccjUueASsTldlXVtMsiqBO8+N8ng3f5qf/2xmPG/zHKqoIRu UIfDknHr4u9fZiZ2W2RlLPre7wyzdEOQdlmTk8adrpW/mO4DjiBWUXiSRqXwezguB2SZ aLE8XLdDfMKlyF3t6R20xjiRh1Vu9iGz1xz3wgwBLOMxXdRLQyFH0p96nuF7hTmKZU9q S8dGS4sxnAvthCeYzXjq7Dds9pUeklTBoEN1ANJp9WYa8exILMekjVz84CiYDJLOiqwM +jBHrMOpstiFfjNUpA2jLVJtYeInVrDJyoBzjM0sKpGXHOn4V3eRZCvNGqbOmM6vuRX1 myyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=nAe56hWX/iMkGrPjUvuhXGh5ni1/NjeEmb5RdJ/Ussc=; b=lx7qeg1A6G2PkRiqALjPbvboktc83kPUOHPnpFNKLX1YrHSOWN/q/jacaD64MUrAML SGRBz9MsZJlsAR0vxQXp1m+yxGYGMhRvg2D0pNkzK8XwJGz13O3Yaj7St7BeBsaRdM+g O9ZUreT+7bFXPe6S2ljrpaOHLVte9K1s0TriaV0EurdAmKuouHS/Ms3hLFVdfL1j18hy EktNF4XI85dJ0nIy6f2LmV/q/GPpzI/isqeOfxohe7wzxuiEpXWRA/YljoA64j/UfCO4 61n3ouR/8k12HM4K5Eq8TzWTBxToZH2Ldmdhhv04hUxZnX2A2GtNgqRG8FB8f+LmKmJl AHaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=G66g0bLN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f23si16333126ejj.531.2021.06.28.21.53.34; Mon, 28 Jun 2021 21:53:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=G66g0bLN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231719AbhF2EzJ (ORCPT + 99 others); Tue, 29 Jun 2021 00:55:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229969AbhF2EzG (ORCPT ); Tue, 29 Jun 2021 00:55:06 -0400 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23B61C061574 for ; Mon, 28 Jun 2021 21:52:39 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id c5so16165548pfv.8 for ; Mon, 28 Jun 2021 21:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=nAe56hWX/iMkGrPjUvuhXGh5ni1/NjeEmb5RdJ/Ussc=; b=G66g0bLNjh/AJ0CJ0kUeXNklSmwJwSgkBCRQvpb6C5iOnIxN6Mvdk6x6OLENG97S4A kSJteKWeEpfadf8SvP2t5wk3AKbv/pzMWRHjrlmEpKiHGr7jxv/+6MnfUUVEXNvz9wsR t8+pMkm5YA4o1e8ks9ArKpT27ECkJIUekUEfNGCTD/xim3499ZsKLQ19VPDhPg6rH/hB FSp3fL0r/FK4Kh5Kd2qtpWCE7ZzGhk59zzDieJ3tGEmm76G/ogewnvvJckNBApn64Nwa ouP7Pru3ur1kHniHr1MOxK5Zt32wvUq5TWytNGDfFxXoZRrCWRcI7dNUGTohM0BBoTDC md7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=nAe56hWX/iMkGrPjUvuhXGh5ni1/NjeEmb5RdJ/Ussc=; b=lVZJPzkjjFQ20Mu4jbuHiIcWwCuRm8S8g/jyetgn+ayofW2KwDa8XORrl6HqFOM07f mEC2D6D+DKUQjl7IBk+aTAZVDUkODKGHvPcvukVCUCYfrizvLr+OvuHU+NWgXemutoyJ Fgup//qid5IEOhPGokhlgJfWJzcr4W5YdamOmVUSkGDQCeOYK15LCOlOpiBRpxnRZRSA rMyIoTXQ6H9QjbpoQRvrFLiVGvHHUVlieY2LeejTWdk8P2BpSDuKQ6MVzwotQGyiazIF XruGT58WrKI+ocRpe2h0ahrv61lBogM/vbrRt9VGJI4+o5EvX5t8y+nkZVN9ZRXTrTim v14Q== X-Gm-Message-State: AOAM530c74O90gpQ65Tgqh69Vynnj9+oz6zY2eQ1e0pyJTHf6Gxaugw4 ChRI5TqffUmhSPn0kcFKSyFhAA== X-Received: by 2002:a63:ba09:: with SMTP id k9mr19146152pgf.340.1624942358511; Mon, 28 Jun 2021 21:52:38 -0700 (PDT) Received: from localhost ([136.185.134.182]) by smtp.gmail.com with ESMTPSA id a23sm16457212pfk.146.2021.06.28.21.52.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Jun 2021 21:52:37 -0700 (PDT) Date: Tue, 29 Jun 2021 10:22:36 +0530 From: Viresh Kumar To: Qian Cai Cc: Ionela Voinescu , Vincent Guittot , Rafael Wysocki , Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Greg Kroah-Hartman , Ingo Molnar , Juri Lelli , Mel Gorman , Peter Zijlstra , "Rafael J. Wysocki" , Steven Rostedt , Sudeep Holla , Will Deacon , "open list:THERMAL" , ACPI Devel Maling List , linux-kernel , "Paul E. McKenney" , "Rafael J. Wysocki" Subject: Re: [PATCH V3 0/4] cpufreq: cppc: Add support for frequency invariance Message-ID: <20210629045236.pmhqactkc7unsjgj@vireshk-i7> References: <20210623041613.v2lo3nidpgw37abl@vireshk-i7> <2c540a58-4fef-5a3d-85b4-8862721b6c4f@quicinc.com> <20210624025414.4iszkovggk6lg6hj@vireshk-i7> <20210624104734.GA11487@arm.com> <20210625102113.GB15540@arm.com> <1f83d787-a796-0db3-3c2f-1ca616eb1979@quicinc.com> <20210625143713.GA7092@arm.com> <888b0178-00cc-ffa4-48a2-8563cef557a4@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <888b0178-00cc-ffa4-48a2-8563cef557a4@quicinc.com> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25-06-21, 22:29, Qian Cai wrote: > Ionela, I found that set ACPI_PROCESSOR=y instead of > ACPI_PROCESSOR=m will fix the previous mentioned issues here (any > explanations of that?) even though the scaling down is not perfect. Not sure how this affects it. > Now, we have the following on this idle system: > > # cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_cur_freq | sort | uniq -c > 79 1000000 > 1 1160000 > 73 1400000 > 1 2000000 > 4 2010000 > 1 2800000 > 1 860000 > > Even if I rerun a few times, there could still have a few CPUs > running lower than lowest_perf (1GHz). (Please wrap your lines at 80 columns, it makes it harder to read otherwise). I think only the counters stopping on idle can get us that. > Also, even though I set all CPUs to use "userspace" governor and set > freq to the lowest. A few CPUs keep changing at will. > > # cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_cur_freq | sort | uniq -c > 156 1000000 > 3 2000000 > 1 760000 I think this is expected since the hardware is in control of frequency here. The software can only request it to run at X frequency, the hardware may choose to do something else nevertheless. -- viresh