From: Steve Muckle <steve.muckle@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux PM list <linux-pm@vger.kernel.org>
Cc: Juri Lelli <juri.lelli@arm.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Michael Turquette <mturquette@baylibre.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [Update][PATCH v7 7/7] cpufreq: schedutil: New governor based on scheduler utilization data
Date: Fri, 1 Apr 2016 10:49:46 -0700 [thread overview]
Message-ID: <56FEB4BA.4080403@linaro.org> (raw)
In-Reply-To: <145931680.Kk1xSBT0Ro@vostro.rjw.lan>
On 03/29/2016 07:00 PM, Rafael J. Wysocki wrote:
...
> +config CPU_FREQ_GOV_SCHEDUTIL
> + tristate "'schedutil' cpufreq policy governor"
> + depends on CPU_FREQ
> + select CPU_FREQ_GOV_ATTR_SET
> + select IRQ_WORK
> + help
> + This governor makes decisions based on the utilization data provided
> + by the scheduler. It sets the CPU frequency to be proportional to
> + the utilization/capacity ratio coming from the scheduler. If the
> + utilization is frequency-invariant, the new frequency is also
> + proportional to the maximum available frequency. If that is not the
> + case, it is proportional to the current frequency of the CPU with the
> + tipping point at utilization/capacity equal to 80%.
This help text implies that the tipping point of 80% applies only to
non-frequency invariant configurations, rather than both. Possible to
rephrase?
...
> +static unsigned int sugov_next_freq_shared(struct sugov_policy *sg_policy,
> + unsigned long util, unsigned long max)
> +{
> + struct cpufreq_policy *policy = sg_policy->policy;
> + unsigned int max_f = policy->cpuinfo.max_freq;
> + u64 last_freq_update_time = sg_policy->last_freq_update_time;
> + unsigned int j;
> +
> + if (util == ULONG_MAX)
> + return max_f;
> +
> + for_each_cpu(j, policy->cpus) {
> + struct sugov_cpu *j_sg_cpu;
> + unsigned long j_util, j_max;
> + u64 delta_ns;
> +
> + if (j == smp_processor_id())
> + continue;
> +
> + j_sg_cpu = &per_cpu(sugov_cpu, j);
> + /*
> + * If the CPU utilization was last updated before the previous
> + * frequency update and the time elapsed between the last update
> + * of the CPU utilization and the last frequency update is long
> + * enough, don't take the CPU into account as it probably is
> + * idle now.
> + */
> + delta_ns = last_freq_update_time - j_sg_cpu->last_update;
> + if ((s64)delta_ns > TICK_NSEC)
>> Why not declare delta_ns as an s64 (also in suguv_should_update_freq)
>> and avoid the cast?
>
> I took this from __update_load_avg(), but it shouldn't matter here.
Did you mean to keep these casts?
thanks,
Steve
next prev parent reply other threads:[~2016-04-01 17:49 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 1:44 [PATCH v6 0/7] cpufreq: schedutil governor Rafael J. Wysocki
2016-03-22 1:46 ` [PATCH v6 1/7][Resend] cpufreq: sched: Helpers to add and remove update_util hooks Rafael J. Wysocki
2016-03-28 5:31 ` Viresh Kumar
2016-03-31 12:47 ` Peter Zijlstra
2016-03-22 1:47 ` [PATCH v6 2/7][Resend] cpufreq: governor: New data type for management part of dbs_data Rafael J. Wysocki
2016-03-22 1:49 ` [PATCH v6 3/7][Resend] cpufreq: governor: Move abstract gov_attr_set code to seperate file Rafael J. Wysocki
2016-03-22 1:50 ` [PATCH v6 4/7][Resend] cpufreq: Move governor attribute set headers to cpufreq.h Rafael J. Wysocki
2016-03-22 1:51 ` [PATCH v6 5/7][Resend] cpufreq: Move governor symbols " Rafael J. Wysocki
2016-03-28 5:35 ` Viresh Kumar
2016-03-22 1:53 ` [PATCH v6 6/7][Resend] cpufreq: Support for fast frequency switching Rafael J. Wysocki
2016-03-26 1:12 ` Steve Muckle
2016-03-26 1:46 ` Rafael J. Wysocki
2016-03-27 1:27 ` Rafael J. Wysocki
2016-03-28 16:47 ` Steve Muckle
2016-03-29 12:10 ` Rafael J. Wysocki
2016-03-28 6:27 ` Viresh Kumar
2016-03-29 12:31 ` Rafael J. Wysocki
2016-03-28 7:03 ` Viresh Kumar
2016-03-29 12:10 ` Rafael J. Wysocki
2016-03-29 14:20 ` Viresh Kumar
2016-03-30 1:47 ` [Update][PATCH v7 6/7] " Rafael J. Wysocki
2016-03-30 5:07 ` Viresh Kumar
2016-03-30 11:28 ` Rafael J. Wysocki
2016-03-22 1:54 ` [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data Rafael J. Wysocki
2016-03-26 1:12 ` Steve Muckle
2016-03-26 2:05 ` Rafael J. Wysocki
2016-03-27 1:36 ` Rafael J. Wysocki
2016-03-28 18:17 ` Steve Muckle
2016-03-29 12:23 ` Rafael J. Wysocki
2016-03-31 12:24 ` Peter Zijlstra
2016-03-31 12:32 ` Rafael J. Wysocki
2016-04-01 18:15 ` Steve Muckle
2016-03-28 9:03 ` Viresh Kumar
2016-03-29 12:58 ` Rafael J. Wysocki
2016-03-30 1:12 ` Rafael J. Wysocki
2016-03-31 12:28 ` Peter Zijlstra
2016-03-30 4:10 ` Viresh Kumar
2016-03-30 2:00 ` [Update][PATCH v7 7/7] " Rafael J. Wysocki
2016-03-30 5:30 ` Viresh Kumar
2016-03-30 11:31 ` Rafael J. Wysocki
2016-03-30 17:05 ` Steve Muckle
2016-03-30 17:24 ` Rafael J. Wysocki
2016-03-31 1:44 ` Steve Muckle
2016-03-31 12:12 ` Peter Zijlstra
2016-03-31 12:18 ` Rafael J. Wysocki
2016-03-31 12:42 ` Peter Zijlstra
2016-03-31 12:48 ` Peter Zijlstra
2016-04-01 17:49 ` Steve Muckle [this message]
2016-04-01 19:14 ` Rafael J. Wysocki
2016-04-01 19:23 ` Steve Muckle
2016-04-01 23:06 ` [Update][PATCH v8 " Rafael J. Wysocki
2016-04-02 1:09 ` Steve Muckle
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=56FEB4BA.4080403@linaro.org \
--to=steve.muckle@linaro.org \
--cc=juri.lelli@arm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mturquette@baylibre.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@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.