From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Nathan Zimmer <nzimmer@sgi.com>
Cc: viresh.kumar@linaro.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, cpufreq@vger.kernel.org
Subject: Re: [PATCH v2 linux-next 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu
Date: Fri, 08 Feb 2013 00:29:36 +0100 [thread overview]
Message-ID: <16615226.2vj4EkkIZJ@vostro.rjw.lan> (raw)
In-Reply-To: <1360116290-23849-3-git-send-email-nzimmer@sgi.com>
On Tuesday, February 05, 2013 08:04:50 PM Nathan Zimmer wrote:
> In general rwlocks are discourged so we are moving it to use the rcu instead.
>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
> Signed-off-by: Nathan Zimmer <nzimmer@sgi.com>
> ---
> drivers/cpufreq/cpufreq.c | 173 +++++++++++++++++++++++++---------------------
> 1 file changed, 96 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index ef25244..a04ceb9 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -39,13 +39,13 @@
> * level driver of CPUFreq support, and its spinlock. This lock
> * also protects the cpufreq_cpu_data array.
> */
> -static struct cpufreq_driver *cpufreq_driver;
> +static struct cpufreq_driver __rcu *cpufreq_driver;
> static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
> #ifdef CONFIG_HOTPLUG_CPU
> /* This one keeps track of the previously set governor of a removed CPU */
> static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
> #endif
> -static DEFINE_RWLOCK(cpufreq_driver_lock);
> +static DEFINE_SPINLOCK(cpufreq_driver_lock);
>
> /*
> * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure
> @@ -143,21 +143,20 @@ static DEFINE_MUTEX(cpufreq_governor_mutex);
> static struct cpufreq_policy *__cpufreq_cpu_get(unsigned int cpu, bool sysfs)
> {
> struct cpufreq_policy *data;
> - unsigned long flags;
> + struct cpufreq_driver *driver;
>
> if (cpu >= nr_cpu_ids)
> goto err_out;
>
> /* get the cpufreq driver */
> - read_lock_irqsave(&cpufreq_driver_lock, flags);
> -
> - if (!cpufreq_driver)
> + rcu_read_lock();
> + driver = rcu_dereference(cpufreq_driver);
> + if (!driver)
> goto err_out_unlock;
>
> - if (!try_module_get(cpufreq_driver->owner))
> + if (!try_module_get(driver->owner))
> goto err_out_unlock;
>
> -
> /* get the CPU */
> data = per_cpu(cpufreq_cpu_data, cpu);
>
> @@ -167,13 +166,13 @@ static struct cpufreq_policy *__cpufreq_cpu_get(unsigned int cpu, bool sysfs)
> if (!sysfs && !kobject_get(&data->kobj))
> goto err_out_put_module;
>
> - read_unlock_irqrestore(&cpufreq_driver_lock, flags);
> + rcu_read_unlock();
> return data;
>
> err_out_put_module:
> - module_put(cpufreq_driver->owner);
> + module_put(driver->owner);
> err_out_unlock:
> - read_unlock_irqrestore(&cpufreq_driver_lock, flags);
> + rcu_read_unlock();
> err_out:
> return NULL;
> }
> @@ -196,7 +195,7 @@ static void __cpufreq_cpu_put(struct cpufreq_policy *data, bool sysfs)
> {
> if (!sysfs)
> kobject_put(&data->kobj);
> - module_put(cpufreq_driver->owner);
> + module_put(rcu_dereference(cpufreq_driver)->owner);
> }
>
> void cpufreq_cpu_put(struct cpufreq_policy *data)
> @@ -267,13 +266,16 @@ static inline void adjust_jiffies(unsigned long val, struct cpufreq_freqs *ci)
> void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
> {
> struct cpufreq_policy *policy;
> + struct cpufreq_driver *driver;
>
> BUG_ON(irqs_disabled());
>
> if (cpufreq_disabled())
> return;
>
> - freqs->flags = cpufreq_driver->flags;
> + driver = rcu_dereference(cpufreq_driver);
Pardon me for not asking that question earlier, but what sense does it make
to use rcu_dereference() outside of an rcu_read_lock()/rcu_read_unlock()
scope? Here and in the other places?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
next prev parent reply other threads:[~2013-02-07 23:23 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 22:45 [PATCH 0/2] cpufreq: cpufreq_driver_lock is hot on large systems Nathan Zimmer
2013-02-04 22:45 ` [PATCH 1/2] cpufreq: Convert the cpufreq_driver_lock to a rwlock Nathan Zimmer
2013-02-05 8:11 ` Viresh Kumar
2013-02-04 22:45 ` [PATCH 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu Nathan Zimmer
2013-02-05 1:07 ` [PATCH 0/2] cpufreq: cpufreq_driver_lock is hot on large systems Rafael J. Wysocki
2013-02-05 8:28 ` Viresh Kumar
2013-02-05 10:03 ` Rafael J. Wysocki
2013-02-05 9:58 ` Viresh Kumar
2013-02-05 10:13 ` Rafael J. Wysocki
2013-02-05 14:58 ` Nathan Zimmer
2013-02-05 22:00 ` Rafael J. Wysocki
2013-02-06 2:04 ` [PATCH v2 linux-next " Nathan Zimmer
2013-02-06 2:04 ` [PATCH v2 linux-next 1/2] cpufreq: Convert the cpufreq_driver_lock to a rwlock Nathan Zimmer
2013-02-06 2:47 ` Viresh Kumar
2013-02-06 2:04 ` [PATCH v2 linux-next 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu Nathan Zimmer
2013-02-06 2:52 ` Viresh Kumar
2013-02-06 8:51 ` Viresh Kumar
2013-02-06 13:00 ` Rafael J. Wysocki
2013-02-07 23:29 ` Rafael J. Wysocki [this message]
2013-02-11 17:13 ` Nathan Zimmer
2013-02-11 19:36 ` Rafael J. Wysocki
2013-02-12 4:03 ` Nathan Zimmer
2013-02-12 15:59 ` Paul E. McKenney
2013-02-13 13:20 ` Rafael J. Wysocki
2013-02-20 23:56 ` [PATCH v3 0/2] cpufreq: cpufreq_driver_lock is hot on large systems Nathan Zimmer
2013-02-20 23:56 ` [PATCH v3 1/2] cpufreq: Convert the cpufreq_driver_lock to a rwlock Nathan Zimmer
2013-02-20 23:56 ` [PATCH v3 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu Nathan Zimmer
2013-02-21 5:50 ` Viresh Kumar
2013-02-21 17:49 ` Nathan Zimmer
2013-02-22 16:24 ` [PATCH v4 0/2] cpufreq: cpufreq_driver_lock is hot on large systems Nathan Zimmer
2013-02-22 16:24 ` [PATCH v4 1/2] cpufreq: Convert the cpufreq_driver_lock to a rwlock Nathan Zimmer
2013-02-23 3:57 ` Viresh Kumar
2013-02-22 16:24 ` [PATCH v4 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu Nathan Zimmer
2013-02-23 3:39 ` Viresh Kumar
2013-02-25 20:07 ` Nathan Zimmer
2013-03-11 23:23 ` [PATCH v4 0/2] cpufreq: cpufreq_driver_lock is hot on large systems Rafael J. Wysocki
2013-03-13 20:50 ` Nathan Zimmer
2013-04-01 15:33 ` [PATCH v5] cpufreq: split the cpufreq_driver_lock and use the rcu (was cpufreq: cpufreq_driver_lock is hot on large systems) Nathan Zimmer
2013-04-01 16:28 ` Viresh Kumar
2013-04-01 17:17 ` Nathan Zimmer
2013-04-01 20:11 ` [PATCH v6 0/2] cpufreq: cpufreq_driver_lock is hot on large systems Nathan Zimmer
2013-04-01 20:11 ` [PATCH v6 1/2] cpufreq: split the cpufreq_driver_lock and use the rcu Nathan Zimmer
2013-04-02 5:05 ` Viresh Kumar
2013-04-02 14:55 ` Nathan Zimmer
2013-04-02 14:59 ` Viresh Kumar
2013-04-02 15:40 ` Nathan Zimmer
2013-04-02 15:52 ` Viresh Kumar
2013-04-02 22:57 ` Rafael J. Wysocki
2013-04-03 5:25 ` Viresh Kumar
2013-04-01 20:11 ` [PATCH v6 2/2] cpufreq: covert the cpufreq_data_lock to a spinlock Nathan Zimmer
2013-04-01 20:41 ` Rafael J. Wysocki
2013-04-02 0:56 ` Nathan Zimmer
2013-04-02 5:04 ` Viresh Kumar
2013-04-02 12:48 ` Rafael J. Wysocki
2013-04-02 14:58 ` Nathan Zimmer
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=16615226.2vj4EkkIZJ@vostro.rjw.lan \
--to=rjw@sisk.pl \
--cc=cpufreq@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nzimmer@sgi.com \
--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 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).