Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1020925ybg; Wed, 3 Jun 2020 21:45:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJweO+s+8ZiVdLfJBnfRwLTpNp9osurJgg100rku/QG0mprV5+0nn++AYCpatKSinEvjgHup X-Received: by 2002:aa7:cd12:: with SMTP id b18mr2627021edw.195.1591245908731; Wed, 03 Jun 2020 21:45:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591245908; cv=none; d=google.com; s=arc-20160816; b=aqSMlzCH24zlh48P+5ohmspGCwIHmYAsRgE6ZYirX2c3NWEj4mwa7Y6EKegFOxcWRq ykEJswYYWf9EuWO7nfvQ3Gx978giM5GQm0XIeb4aNjvsUBnnEEad9ygDgP1jywQ22rHE CFlgx2F/vX9X/JKjWgrTvEPu597mQeC96JAU+lxDUuAOIH3iu940MYQSp9X+6UCJCTOM w+GPjYh7IPRul1FKG/V+Dueac1SItXw/MsCS/W/ge5RvdOdVmcwxIIpC4KqDFlA3STau FPV3hI2FzlyQyE/XR2bhJw/KUNQbJzqVjXTZkUYeHe/EuqCo05Q5WpSVaakIVQoyvJm0 hR2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=8WDlsjrMlty5dE62ZezIYU+NL84xC3Chb0nBV1myZPA=; b=EY4IZ7iJyFP7TsOarstLNbRTob7JEmxqIabhOKInJllGydNHVxa7WzKxF3PlK8IGLP 1mu0QDdnA87FIQgG5ZingyVXi8zfTiYsywbFolimeaaDoY/PbazBP+rgoMcTxeRxADwD 6i7Z/vtGky0M6AoXBLJo1JM/BsygpNuCoJB2ay2X0oTfMpf79XDfwttr+HA48GsDdkgz DEDigyoag39cIdj6shJmKWuHn3jE5Apv9X9R5Yd3rnnX+IFvKUoOR8uXmmvUic5wf5EL JhVag5f8oaOam6zOKnuGohhzv2ECDwWIrRijbiSyHNuChBukl+0luxeYdh+l5HmlMFoH LC4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="U/1Y6fc0"; 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 c25si961575edw.456.2020.06.03.21.44.45; Wed, 03 Jun 2020 21:45:08 -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="U/1Y6fc0"; 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 S1727043AbgFDElp (ORCPT + 99 others); Thu, 4 Jun 2020 00:41:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726456AbgFDElp (ORCPT ); Thu, 4 Jun 2020 00:41:45 -0400 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1C73C05BD1E for ; Wed, 3 Jun 2020 21:41:44 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id bg4so1649255plb.3 for ; Wed, 03 Jun 2020 21:41:44 -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=8WDlsjrMlty5dE62ZezIYU+NL84xC3Chb0nBV1myZPA=; b=U/1Y6fc0FsAR9q/fDRBBbl4f4ErUS4R91YBctvPmeCyz4QlZMRhbPe4f3+74RBGRWd dDgiXGgYoKG17vzZO21zRqkMlPQ/6TUV4Q71GTsjSjlr6Q2dLJNH8A34GhmXD74O8+EZ JDkIItQE0Tv6jEgvHP5H5CHgsGZ8cShuYQuNKk4GcxBLssCRu/T6Tb2ZCAJI8yy0w6Yj QMNEX9HsXX0bGHCinzKIUrSGirJxIanJ+uVuEtVjq/zxV3JCBaIzLh83xWD0aJYjQAE0 /e3WnZwWiZAIpHKSLhRejOEOE9ZrbjOUFCGZORu6AVHywzoxSv6NsdHF2grmh8Q4sv7Q T1Lg== 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=8WDlsjrMlty5dE62ZezIYU+NL84xC3Chb0nBV1myZPA=; b=FYZ/SfQLXy79cQQdnImWGKbRdekvKtUffHBgRQSYzYIOEzQMkw/RSJH2U1Uzen9Wz0 6zOAzarYCu4dNudxrkzB1Eo68hjcYi19CdYJmyKV3ILMppkP2dEtVQFp99/Or7Hv73t4 nbPsNjlRIFw2NPqnoFSfO7Lc7xWJlyHDeVizWRTgeiegSsFjXzCFeuhdlt1Sx6oelEsd XSoCz3/JGxlQtTJ37mX7SXJG+O+YdkONTjATGMQnPgFS+ZBJjojfT01ph1pxUlM/MLbJ bq6otvNOkVYYTSFCEWYaTdUqGkBEojjfF1VLFqydlf93JKsI7Qlprut3slEjjxzi/V6v nmug== X-Gm-Message-State: AOAM530/aVkB6sL5HoAIKbDemyeF8E6/5dnoOofiLAKI1QvMx0SjAKCS 38FC6clsi8N9t1uiQ0Edea0yyw== X-Received: by 2002:a17:90b:2042:: with SMTP id ji2mr3896276pjb.68.1591245704073; Wed, 03 Jun 2020 21:41:44 -0700 (PDT) Received: from localhost ([122.172.62.209]) by smtp.gmail.com with ESMTPSA id p14sm4185557pju.7.2020.06.03.21.41.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2020 21:41:43 -0700 (PDT) Date: Thu, 4 Jun 2020 10:11:40 +0530 From: Viresh Kumar To: Xiongfeng Wang Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Hanjun Guo , Sudeep Holla , Ionela Voinescu , Linux PM , Linux Kernel Mailing List Subject: Re: [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU is in idle state Message-ID: <20200604044140.xlv7h62jfowo3rxe@vireshk-i7> References: <20200603075200.hbyofgcyiwocl565@vireshk-i7> <39d37e1b-7959-9a8f-6876-f2ed4c1dbc37@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39d37e1b-7959-9a8f-6876-f2ed4c1dbc37@huawei.com> User-Agent: NeoMutt/20180716-391-311a52 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04-06-20, 09:32, Xiongfeng Wang wrote: > On 2020/6/3 21:39, Rafael J. Wysocki wrote: > > The frequency value obtained by kicking the CPU out of idle > > artificially is bogus, though. You may as well return a random number > > instead. > > Yes, it may return a randowm number as well. > > > > > The frequency of a CPU in an idle state is in fact unknown in the case > > at hand, so returning 0 looks like the cleanest option to me. > > I am not sure about how the user will use 'cpuinfo_cur_freq' in sysfs. If I > return 0 when the CPU is idle, when I run a light load on the CPU, I will get a > zero value for 'cpuinfo_cur_freq' when the CPU is idle. When the CPU is not > idle, I will get a non-zero value. The user may feel odd about > 'cpuinfo_cur_frreq' switching between a zero value and a non-zero value. They > may hope it can return the frequency when the CPU execute instructions, namely > in C0 state. I am not so sure about the user will look at 'cpuinfo_cur_freq'. This is what I was worried about as well. The interface to sysfs needs to be robust. Returning frequency on some readings and 0 on others doesn't look right to me as well. This will break scripts (I am not sure if some scripts are there to look for these values) with the randomness of values returned by it. On reading values locally from the CPU, I thought about the case where userspace can prevent a CPU going into idle just by reading its frequency from sysfs (and so waste power), but the same can be done by userspace to run arbitrary load on the CPUs. Can we do some sort of caching of the last frequency the CPU was running at before going into idle ? Then we can just check if cpu is idle and so return cached value. -- viresh