All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Xiongfeng Wang <wangxiongfeng2@huawei.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Hanjun Guo <guohanjun@huawei.com>,
	Ionela Voinescu <ionela.voinescu@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Linux PM <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU is in idle state
Date: Thu, 4 Jun 2020 13:58:22 +0100	[thread overview]
Message-ID: <20200604125822.GB12397@bogus> (raw)
In-Reply-To: <CAJZ5v0jj5OS4oB7MYBqKeYejy_3Vz_2oy0hn-Xm=D7XAszM_vg@mail.gmail.com>

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

  reply	other threads:[~2020-06-04 12:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-02  3:34 [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU is in idle state Xiongfeng Wang
2020-06-03  2:05 ` Hanjun Guo
2020-06-03  7:52 ` Viresh Kumar
2020-06-03 10:07   ` Sudeep Holla
2020-06-03 10:10     ` Viresh Kumar
2020-06-03 10:17       ` Sudeep Holla
2020-06-03 10:21         ` Viresh Kumar
2020-06-03 10:40           ` Sudeep Holla
2020-06-03 13:39   ` Rafael J. Wysocki
2020-06-04  1:32     ` Xiongfeng Wang
2020-06-04  4:41       ` Viresh Kumar
2020-06-04 10:42         ` Rafael J. Wysocki
2020-06-04 12:58           ` Sudeep Holla [this message]
2020-06-10  9:40             ` Ionela Voinescu
2020-06-11  1:52               ` Xiongfeng Wang
2020-06-12 11:55                 ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200604125822.GB12397@bogus \
    --to=sudeep.holla@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=ionela.voinescu@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=viresh.kumar@linaro.org \
    --cc=wangxiongfeng2@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.