Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1515360ybg; Thu, 4 Jun 2020 11:37:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwqEncnblFCgxKzG/FoCzuOj0ik6i1THYHEeIPxYT+FIKr4dEfIGa9+6BMu4kxgH0OuWe4K X-Received: by 2002:a05:6402:1606:: with SMTP id f6mr5509852edv.286.1591295858593; Thu, 04 Jun 2020 11:37:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591295858; cv=none; d=google.com; s=arc-20160816; b=PTzZ21Z7C0rj0KwWejcHn8HgbbPblyTkChRD8C4wJr7u5ZNhIuyPLTyU9LU9IQDxeT JmZCs9dWG9OCaQUT+eiEIisA6JimHbLbxcy5LYIjKolzTZiC0ZyfFNWlxSf068FVcDlf nhNJcMDa1y5RrCtt9VsNMhF1ZPBuJ97Zqf5xuciCRM90K0SA/9xDVxlz9eNM3Td7gL7h NWWZCJMWm6azAAETnVZ+O3U5VueEj+eNZy/2+x5bdkzrgUlRX7oTeGpqXRZEs1TIa7+P PuE0t4bsI5HO7aYZgVoxV02JWeQ9tA1SaAlfOYZa8t9b4EeC1WmAx1Kvs8QiD1Uvo1bn M5EQ== 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; bh=CVclmbcwuVCxGTfjsM8Gb/w817tcHat0Oe5xSgDWH7g=; b=UcXt18hScnEi1AYHW3RKHTx7RlFOaySSP/L3TWso+KOtogEzgR6BPz/56Pgu6VnZy2 yshRQjinZUp4K/oGO/hM7Xmh7OFlR/Fq7dqDxdG4aC1/SqELIHjevTDjQUBxfuP1OeCF 3szZuRLOtO2IrIeczjBN+Re5B3F/95ECdt/nUHIwZ6Bwq+UfnZy1kJLlTyJi8Rkkvo4e nWnv9n5ASs9aidjFGwHGg6BevX/7O0L65kBdJJ1T/4IMCd7o4fGTIZVYbrZ3HNxlNVfn HfBYXCUB7x6RTWdZUZwcOyzmcYkyQ/qUw95IukSpDe8yEMDf2RgHFF+hMufvIOJPPrcz qwDg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n5si2025378eji.356.2020.06.04.11.37.15; Thu, 04 Jun 2020 11:37:38 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728291AbgFDM63 (ORCPT + 99 others); Thu, 4 Jun 2020 08:58:29 -0400 Received: from foss.arm.com ([217.140.110.172]:44228 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726221AbgFDM63 (ORCPT ); Thu, 4 Jun 2020 08:58:29 -0400 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 66B6930E; Thu, 4 Jun 2020 05:58:28 -0700 (PDT) Received: from bogus (unknown [10.37.12.7]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B3C643F305; Thu, 4 Jun 2020 05:58:25 -0700 (PDT) Date: Thu, 4 Jun 2020 13:58:22 +0100 From: Sudeep Holla To: "Rafael J. Wysocki" Cc: Viresh Kumar , Xiongfeng Wang , "Rafael J. Wysocki" , Hanjun Guo , Ionela Voinescu , Sudeep Holla , 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: <20200604125822.GB12397@bogus> References: <20200603075200.hbyofgcyiwocl565@vireshk-i7> <39d37e1b-7959-9a8f-6876-f2ed4c1dbc37@huawei.com> <20200604044140.xlv7h62jfowo3rxe@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 04, 2020 at 12:42:06PM +0200, Rafael J. Wysocki wrote: > 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. > +1 for dropping the attribute. -- Regards, Sudeep