From: Saravana Kannan <skannan@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
sboyd@codeaurora.org, prarit@redhat.com
Subject: Re: [PATCH 05/18] cpufreq: Manage governor usage history with 'policy->last_governor'
Date: Wed, 11 Feb 2015 19:03:34 -0800 [thread overview]
Message-ID: <54DC1806.9040001@codeaurora.org> (raw)
In-Reply-To: <bc7154266269beb8c6b9b3d56b529b64db33d2e2.1422346933.git.viresh.kumar@linaro.org>
On 01/27/2015 12:36 AM, Viresh Kumar wrote:
> History of which governor was used last is common to all CPUs within a policy
> and maintaining it per-cpu isn't the best approach for sure.
>
> Apart from wasting memory, this also increases the complexity of managing this
> data structure as it has to be updated for all CPUs.
>
> To make that somewhat simpler, lets store this information in a new field
> 'last_governor' in struct cpufreq_policy and update it on removal of last cpu of
> a policy.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/cpufreq.c | 24 ++++++++++++------------
> include/linux/cpufreq.h | 1 +
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index f253cf45f910..4ad1e46891b5 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -57,9 +57,6 @@ static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
> static DEFINE_RWLOCK(cpufreq_driver_lock);
> DEFINE_MUTEX(cpufreq_governor_lock);
>
> -/* This one keeps track of the previously set governor of a removed CPU */
> -static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
> -
> /* Flag to suspend/resume CPUFreq governors */
> static bool cpufreq_suspended;
>
> @@ -941,7 +938,7 @@ static void cpufreq_init_policy(struct cpufreq_policy *policy)
> memcpy(&new_policy, policy, sizeof(*policy));
>
> /* Update governor of new_policy to the governor used before hotplug */
> - gov = find_governor(per_cpu(cpufreq_cpu_governor, policy->cpu));
> + gov = find_governor(policy->last_governor);
Just change this to:
gov = policy->governor;
No need to search for the governor again. It should already be valid for
policy that's being restored. For new policies, it would be NULL and
would get defaulted correctly.
> if (gov)
> pr_debug("Restoring governor %s for cpu %d\n",
> policy->governor->name, policy->cpu);
> @@ -1366,8 +1363,9 @@ static int __cpufreq_remove_dev_prepare(struct device *dev,
> return ret;
> }
>
> - strncpy(per_cpu(cpufreq_cpu_governor, cpu),
> - policy->governor->name, CPUFREQ_NAME_LEN);
> + if (cpus == 1)
> + strncpy(policy->last_governor, policy->governor->name,
> + CPUFREQ_NAME_LEN);
> }
>
> if (cpu != policy->cpu) {
> @@ -2096,7 +2094,8 @@ EXPORT_SYMBOL_GPL(cpufreq_register_governor);
>
> void cpufreq_unregister_governor(struct cpufreq_governor *governor)
> {
> - int cpu;
> + struct cpufreq_policy *policy;
> + unsigned long flags;
>
> if (!governor)
> return;
> @@ -2104,12 +2103,13 @@ void cpufreq_unregister_governor(struct cpufreq_governor *governor)
> if (cpufreq_disabled())
> return;
>
> - for_each_present_cpu(cpu) {
> - if (cpu_online(cpu))
> - continue;
> - if (!strcmp(per_cpu(cpufreq_cpu_governor, cpu), governor->name))
> - strcpy(per_cpu(cpufreq_cpu_governor, cpu), "\0");
> + /* clear last_governor for all fallback policies */
> + read_lock_irqsave(&cpufreq_driver_lock, flags);
> + for_each_fallback_policy(policy) {
> + if (!strcmp(policy->last_governor, governor->name))
> + strcpy(policy->last_governor, "\0");
> }
> + read_unlock_irqrestore(&cpufreq_driver_lock, flags);
>
> mutex_lock(&cpufreq_governor_mutex);
> list_del(&governor->governor_list);
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index df6af4cfa26a..e326cddef6db 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -80,6 +80,7 @@ struct cpufreq_policy {
> struct cpufreq_governor *governor; /* see below */
> void *governor_data;
> bool governor_enabled; /* governor start/stop flag */
> + char last_governor[CPUFREQ_NAME_LEN]; /* last governor used */
>
> struct work_struct update; /* if update_policy() needs to be
> * called, but you're in IRQ context */
>
Kinda Nack for a couple of reasons:
1. For logical hotplugs, we don't really throw away the policy, so the
governor pointer should already be the last governor. We can just use
the pointer.
2. For physical hotplug of CPUs, the policies are getting freed (I
assume and hope so). So, the "last_governor" field is going to be empty.
3. Even if we continue storing the last_governor outside of the policy,
for physical hotplug of CPUs where the policy is getting recreated, I'm
not sure restoring the governor is the right thing to do anyway. I'll
explain various possible configurations below for the physical hotplug case:
a. Single policy for all CPUs: The policy never gets removed since
there'll be at least one CPU present. So the save/restore code is never
used.
b. Multi-cluster/policy system with per-policy tunables enabled:
Restoring the governor is bad/incomplete since the per-policy tunables
are lost when the governor gets POLICY_EXIT when the policy is
destroyed. IMO, in these cases, it's better to use the default governor
since we know that using it at cpufreq init with the default tunables
for it is a safe/nice configuration.
c. Multi-cluster/policy system with global tunables: Restoring the
governor works for this case, but I think it's still better to use the
default governor to be consistent with (b) and IMO it makes more sense
since the CPU is getting physically added for the first time.
So, long story short, I think this patch should be changed to:
1. Use policy->governor instead of find_governor(last_governor)
2. Use default governor if policy->governor is NULL
3. Completely delete all references to last_governor.
Thanks,
Saravana
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-02-12 3:03 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-27 8:36 [PATCH 00/18] cpufreq: don't loose cpufreq history on CPU hotplug Viresh Kumar
2015-01-27 8:36 ` [PATCH 01/18] cpufreq: Drop cpufreq_disabled() check from cpufreq_cpu_{get|put}() Viresh Kumar
2015-02-03 22:17 ` Saravana Kannan
2015-01-27 8:36 ` [PATCH 02/18] cpufreq: Create for_each_policy() Viresh Kumar
2015-02-03 22:22 ` Saravana Kannan
2015-02-04 4:53 ` Viresh Kumar
2015-01-27 8:36 ` [PATCH 03/18] cpufreq: Create for_each_governor() Viresh Kumar
2015-02-03 22:23 ` Saravana Kannan
2015-01-27 8:36 ` [PATCH 04/18] cpufreq: Manage fallback policies in a list Viresh Kumar
2015-02-03 0:41 ` Rafael J. Wysocki
2015-02-03 4:10 ` Viresh Kumar
2015-02-03 15:04 ` Rafael J. Wysocki
2015-02-04 6:18 ` Viresh Kumar
2015-02-03 22:28 ` Saravana Kannan
2015-02-04 6:20 ` Viresh Kumar
2015-02-04 22:28 ` Saravana Kannan
2015-02-04 23:20 ` Rafael J. Wysocki
2015-02-05 1:55 ` Saravana Kannan
2015-02-05 15:11 ` Rafael J. Wysocki
2015-02-05 22:55 ` Saravana Kannan
2015-02-17 8:06 ` Viresh Kumar
2015-02-17 18:15 ` Rafael J. Wysocki
2015-02-18 4:23 ` Viresh Kumar
2015-02-18 21:15 ` Saravana Kannan
2015-02-19 3:24 ` Viresh Kumar
2015-01-27 8:36 ` [PATCH 05/18] cpufreq: Manage governor usage history with 'policy->last_governor' Viresh Kumar
2015-02-12 3:03 ` Saravana Kannan [this message]
2015-02-12 7:44 ` Viresh Kumar
2015-02-12 8:00 ` skannan
2015-02-17 8:02 ` Viresh Kumar
2015-01-27 8:36 ` [PATCH 06/18] cpufreq: Reuse policy list instead of per-cpu variable 'cpufreq_cpu_data' Viresh Kumar
2015-02-12 3:13 ` Saravana Kannan
2015-02-12 7:48 ` Viresh Kumar
2015-01-27 8:36 ` [PATCH 07/18] cpufreq: Drop (now) useless check 'cpu > nr_cpu_ids' Viresh Kumar
2015-02-12 3:15 ` Saravana Kannan
2015-02-12 7:50 ` Viresh Kumar
2015-01-27 8:36 ` [PATCH 08/18] cpufreq: Add doc style comment about cpufreq_cpu_{get|put}() Viresh Kumar
2015-02-12 3:19 ` Saravana Kannan
2015-02-12 7:52 ` Viresh Kumar
2015-01-27 8:36 ` [PATCH 09/18] cpufreq: Mark policy->governor = NULL for fallback policies Viresh Kumar
2015-02-12 3:22 ` Saravana Kannan
2015-02-12 7:56 ` Viresh Kumar
2015-01-27 8:36 ` [PATCH 10/18] cpufreq: Don't allow updating inactive-policies from sysfs Viresh Kumar
2015-02-12 3:24 ` Saravana Kannan
2015-01-27 8:36 ` [PATCH 11/18] cpufreq: Track cpu managing sysfs kobjects separately Viresh Kumar
2015-01-27 8:36 ` [PATCH 12/18] cpufreq: Stop migrating sysfs files on hotplug Viresh Kumar
2015-01-27 8:36 ` [PATCH 13/18] cpufreq: Keep a single path for adding managed CPUs Viresh Kumar
2015-01-27 8:36 ` [PATCH 14/18] cpufreq: Remove cpufreq_update_policy() Viresh Kumar
2015-01-27 8:36 ` [PATCH 15/18] cpufreq: Initialize policy->kobj while allocating policy Viresh Kumar
2015-01-27 8:36 ` [PATCH 16/18] cpufreq: Call cpufreq_policy_put_kobj() from cpufreq_policy_free() Viresh Kumar
2015-01-27 8:36 ` [PATCH 17/18] cpufreq: Restart governor as soon as possible Viresh Kumar
2015-01-27 8:36 ` [PATCH 18/18] cpufreq: Merge __cpufreq_add_dev() and cpufreq_add_dev() Viresh Kumar
2015-01-27 15:06 ` [PATCH 00/18] cpufreq: don't loose cpufreq history on CPU hotplug Rafael J. Wysocki
2015-01-27 14:59 ` Viresh Kumar
2015-01-28 19:35 ` Saravana Kannan
2015-01-29 1:43 ` Viresh Kumar
2015-02-03 0:30 ` 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=54DC1806.9040001@codeaurora.org \
--to=skannan@codeaurora.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=prarit@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=sboyd@codeaurora.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.