From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Lukasz Luba <lukasz.luba@arm.com>,
Rafael Wysocki <rjw@rjwysocki.net>,
Linux PM <linux-pm@vger.kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
cristian.marussi@arm.com, Sudeep Holla <sudeep.holla@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 1/4] cpufreq: stats: Defer stats update to cpufreq_stats_record_transition()
Date: Thu, 24 Sep 2020 18:09:21 +0530 [thread overview]
Message-ID: <20200924123921.iiaqw2ufe2utnjtg@vireshk-i7> (raw)
In-Reply-To: <CAJZ5v0hkBnU_W-ZXHTfppu9pVWnQcJHho7DQPi7N7yeLOt5cgg@mail.gmail.com>
On 24-09-20, 13:07, Rafael J. Wysocki wrote:
> On Thu, Sep 24, 2020 at 1:00 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
> > On 9/24/20 11:24 AM, Rafael J. Wysocki wrote:
> > > On Thu, Sep 24, 2020 at 11:25 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
> > >> I wonder if we could just drop the reset feature. Is there a tool
> > >> which uses this file? The 'reset' sysfs would probably have to stay
> > >> forever, but an empty implementation is not an option?
> > >
> > > Well, having an empty sysfs attr would be a bit ugly, but the
> > > implementation of it could be simplified.
> > >
> > >> The documentation states:
> > >> 'This can be useful for evaluating system behaviour under different
> > >> governors without the need for a reboot.'
> > >> With the scenario of fast-switch this resetting complicates the
> > >> implementation and the justification of having it just for experiments
> > >> avoiding reboot is IMO weak. The real production code would have to pay
> > >> extra cycles every time. Also, we would probably not experiment with
> > >> cpufreq different governors, since the SchedUtil is considered the best
> > >> option.
> > >
> > > It would still be good to have a way to test it against the other
> > > available options, though.
> > >
> >
> > Experimenting with different governors would still be possible, just
> > the user-space would have to take a snapshot of the stats when switching
> > to a new governor. Then the values presented in the stats would just
> > need to be calculated in this user tool against the snapshot.
> >
> > The resetting is also not that bad, since nowadays more components
> > maintain some kind of local statistics/history (scheduler, thermal).
> > I would recommend to reset the whole system and repeat the same tests
> > with different governor, just to be sure that everything starts from
> > similar state (utilization, temperature, other devfreq devices
> > frequencies etc).
>
> Well, if everyone agrees on removing the reset feature, let's drop the
> sysfs attr too, as it would be useless going forward.
>
> Admittedly, I don't have a strong opinion and since intel_pstate
> doesn't use a frequency table, this is not relevant for systems using
> that driver anyway.
I added this file sometime back as it made my life a lot easier while testing
some scheduler related changes and see how they affect cpufreq updates. IMO this
is a useful feature and we don't really need to get rid of it.
Lets see where the discussion goes about the feedback you gave.
--
viresh
next prev parent reply other threads:[~2020-09-24 12:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-16 6:45 [PATCH V2 0/4] cpufreq: Record stats with fast-switching Viresh Kumar
2020-09-16 6:45 ` [PATCH V2 1/4] cpufreq: stats: Defer stats update to cpufreq_stats_record_transition() Viresh Kumar
2020-09-23 13:48 ` Rafael J. Wysocki
2020-09-24 9:25 ` Lukasz Luba
2020-09-24 10:24 ` Rafael J. Wysocki
2020-09-24 11:00 ` Lukasz Luba
2020-09-24 11:07 ` Rafael J. Wysocki
2020-09-24 12:39 ` Viresh Kumar [this message]
2020-09-24 16:10 ` Lukasz Luba
2020-09-25 6:09 ` Viresh Kumar
2020-09-25 8:10 ` Lukasz Luba
2020-09-24 13:15 ` Viresh Kumar
2020-09-25 10:04 ` Rafael J. Wysocki
2020-09-25 10:58 ` Viresh Kumar
2020-09-25 11:09 ` Rafael J. Wysocki
2020-09-25 11:26 ` Viresh Kumar
2020-09-25 8:21 ` Lukasz Luba
2020-09-25 10:46 ` Viresh Kumar
2020-09-16 6:45 ` [PATCH V2 2/4] cpufreq: stats: Remove locking Viresh Kumar
2020-09-16 6:45 ` [PATCH V2 3/4] cpufreq: stats: Enable stats for fast-switch as well Viresh Kumar
2020-09-23 15:14 ` Rafael J. Wysocki
2020-09-23 15:17 ` Rafael J. Wysocki
2020-09-16 6:45 ` [PATCH V2 4/4] cpufreq: Move traces and update to policy->cur to cpufreq core Viresh Kumar
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=20200924123921.iiaqw2ufe2utnjtg@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=cristian.marussi@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).