Messages in this thread | | | Date | Thu, 4 Jun 2020 13:58:22 +0100 | From | Sudeep Holla <> | Subject | Re: [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU is in idle state |
| |
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 <viresh.kumar@linaro.org> 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
| |