linux-kernel - Re: [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU is in idle state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200604044140.xlv7h62jfowo3rxe@vireshk-i7>
Date:   Thu, 4 Jun 2020 10:11:40 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Xiongfeng Wang <wangxiongfeng2@...wei.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Hanjun Guo <guohanjun@...wei.com>,
        Sudeep Holla <Sudeep.Holla@....com>,
        Ionela Voinescu <ionela.voinescu@....com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU
 is in idle state

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