From: Viresh Kumar <viresh.kumar@linaro.org>
To: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
linux-pm@vger.kernel.org,
Vincent Guittot <vincent.guittot@linaro.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate
Date: Fri, 30 Jun 2017 09:04:25 +0530 [thread overview]
Message-ID: <20170630033425.GU29665@vireshk-i7> (raw)
In-Reply-To: <20170629180123.GA2443@light.dominikbrodowski.net>
On 29-06-17, 20:01, Dominik Brodowski wrote:
> On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote:
> > The cpufreq core and governors aren't supposed to set a limit on how
> > fast we want to try changing the frequency. This is currently done for
> > the legacy governors with help of min_sampling_rate.
> >
> > At worst, we may end up setting the sampling rate to a value lower than
> > the rate at which frequency can be changed and then one of the CPUs in
> > the policy will be only changing frequency for ever.
>
> Is it safe to issue requests to change the CPU frequency so frequently,
Well, I assumed so. I am not sure the hardware would break though.
Overheating ?
> even
> on historic hardware such as speedstep-{ich,smi,centrino}? In the past,
> these checks more or less disallowed the running of dynamic frequency
> scaling at least on speedstep-smi[*],
We must by doing dynamic freq scaling even without this patch. I don't
see why you say the above then.
All we do here is that we get rid of the limit on how soon we can
change the freq again.
> but maybe on a few other platforms as
> well. That's why I am curious on whether this may break systems potentially
> on a hardware level if the hardware was not designed to do dynamic frequency
> scaling (and not just frequency switches on battery/AC).
Honestly I am not sure if any hardware can break or not, just because
of this commit.
--
viresh
next prev parent reply other threads:[~2017-06-30 3:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 10:59 [PATCH 0/6] cpufreq: transition-latency cleanups Viresh Kumar
2017-06-29 10:59 ` [PATCH 1/6] cpufreq: Don't check for max_transition_latency Viresh Kumar
2017-06-29 10:59 ` [PATCH 2/6] cpufreq: Remove (now) unused code related to max_transition_latency Viresh Kumar
2017-06-29 10:59 ` [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate Viresh Kumar
2017-06-29 18:01 ` Dominik Brodowski
2017-06-30 3:34 ` Viresh Kumar [this message]
2017-06-30 4:53 ` Dominik Brodowski
2017-06-30 5:40 ` Viresh Kumar
2017-07-02 7:23 ` Dominik Brodowski
2017-06-29 10:59 ` [PATCH 4/6] cpufreq: Use transition_delay_us for legacy governors as well Viresh Kumar
2017-06-29 10:59 ` [PATCH 5/6] cpufreq: Cap the default transition delay value to 10 ms Viresh Kumar
2017-06-29 10:59 ` [PATCH 6/6] cpufreq: arm_big_little: Make ->get_transition_latency() mandatory Viresh Kumar
2017-06-29 20:36 ` [PATCH 0/6] cpufreq: transition-latency cleanups 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=20170630033425.GU29665@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=rjw@rjwysocki.net \
--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 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.