Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1199935ybg; Thu, 4 Jun 2020 03:47:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5G7EI+3/QOsz0hr2R5GhWC8B06kZeGrlqb7VhFHXXoovDRZHV7ta8w2WgEvcvVzW1jKea X-Received: by 2002:a50:a701:: with SMTP id h1mr2375185edc.170.1591267654421; Thu, 04 Jun 2020 03:47:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591267654; cv=none; d=google.com; s=arc-20160816; b=OK+C7/Nu6CEOcc0OHqzMLwSpO5cimaMxtoH8Xkws+oT9ZGMnHNTAYsmx2i7C2OpgQt XiaLXeYTUPZ+Lee7e7Ptnwc2AYteiVtBxvMOV/xpT7Qo3WMQuAscRi2Gao1u91PuqgVN mtvMIXcbPhgx7qWSMTZDsyHYFrOI3x5DWr3BZgbkegnMOahA14Z2mi1Jgj75Oro57ioF XBmYkB27iOwHkSuqEvEU1TTsOfv6DSbfsB3K4JBjM+88LE3FbZ1DHVmeWx465/2LVbY4 T4fi4+02Cjjo3kC+EBoEvTnGHR45eUlWKSFeYvBlLsGfoC1Za68TZRCvMmL8aFdYGph2 KDsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=MtLNfsN/A/N2E3wGVViMKTHPXKwZLxoBNdSqzHaE8IA=; b=XJB/aJpIn3KTXVXDqpz/vEBDo7PFRSzkZfgJFSzqpaUR/4gcWQTaXhyiWWfkUB8QhJ KQGm4dhFMmc15x4GfP8/McpEsAmnDeIjNd18gS/9pR4l3Gpe2ERrK7wfJO5PW0He10Tl pTsGPJNPC1BAhsfL95vDRE2b+c4YUTIXx2OoUEuB5JYBMEJS9HCPpK3i+gCmZsQctb/B CFpdW8JDPg4qvRNkTaE7XGa6p5r0nCMq4XgRd9+A6j1AaU5h5wWCDG/tv7M3MGDafd4W alPxbfME1el5WAQ+6r3LnT3QDn0eL3yGjd141mITg2Ay7HUbIRdB3UhMJhev+MTbMwbz DzGg== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r6si1485319edx.97.2020.06.04.03.47.11; Thu, 04 Jun 2020 03:47:34 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726216AbgFDKmU (ORCPT + 99 others); Thu, 4 Jun 2020 06:42:20 -0400 Received: from mail-oi1-f170.google.com ([209.85.167.170]:39957 "EHLO mail-oi1-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726047AbgFDKmU (ORCPT ); Thu, 4 Jun 2020 06:42:20 -0400 Received: by mail-oi1-f170.google.com with SMTP id t25so4641890oij.7; Thu, 04 Jun 2020 03:42:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MtLNfsN/A/N2E3wGVViMKTHPXKwZLxoBNdSqzHaE8IA=; b=TJgUvPw4HOhKa1RKyZx1yhqfeWlnJRqajjAbpdn8XEdkZ3L7yMKindhHxkfljFWGln RDOjrSBcaKqdIKhBADlWaKzeKoR4P2ALaUrsc7+AzlwyRAQ5TlmL/MLNnjbcv/fkdQdZ MZnlYmqUVrcesFft/AWRCnUKe+pVHTcXIpsLbP94vUNQ3yJH59gS9qhbtdaH73nOGoC3 E2jSWblAocsZsjqk+PGBGrS6qUhQRyB+aM+nV8fcq2ds3K2d14TsrdoT0gKidz9/p5Ab K+3bl0JubX9WriK00QfqvqVIcsn0xk6qlmijCtmc+a/72QRpOJrkNlL18niPwHZUbvHO J61g== X-Gm-Message-State: AOAM533I17OgN6WcOr0Ri9PWnsDl6ZGlC5fPimJCoS4NjyONFg5UlnRO mEXfYu06dTZprE+GyftecJpdCb+YtbTFJbkHUhE= X-Received: by 2002:aca:ad88:: with SMTP id w130mr2754792oie.103.1591267339260; Thu, 04 Jun 2020 03:42:19 -0700 (PDT) MIME-Version: 1.0 References: <20200603075200.hbyofgcyiwocl565@vireshk-i7> <39d37e1b-7959-9a8f-6876-f2ed4c1dbc37@huawei.com> <20200604044140.xlv7h62jfowo3rxe@vireshk-i7> In-Reply-To: <20200604044140.xlv7h62jfowo3rxe@vireshk-i7> From: "Rafael J. Wysocki" Date: Thu, 4 Jun 2020 12:42:06 +0200 Message-ID: Subject: Re: [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU is in idle state To: Viresh Kumar Cc: Xiongfeng Wang , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Hanjun Guo , Sudeep Holla , Ionela Voinescu , Linux PM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 4, 2020 at 6:41 AM Viresh Kumar wrote: > > 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. The only thing the scripts need to do is to skip zeros (or anything less than the minimum hw frequency for that matter) coming from that attribute. > 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. That is an option, but it looks like in this case the cpuinfo_cur_freq attribute should not be present at all, as per the documentation. Cheers!