All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Zimmer <nzimmer@sgi.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: rjw@sisk.pl, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu
Date: Thu, 21 Feb 2013 11:49:03 -0600	[thread overview]
Message-ID: <51265E0F.6090209@sgi.com> (raw)
In-Reply-To: <CAKohponMWRPspZF=tPN6MXoxkcjw7CK_sLnSdsKe+EDoiADvGA@mail.gmail.com>

On 02/20/2013 11:50 PM, Viresh Kumar wrote:
> On 21 February 2013 05:26, Nathan Zimmer <nzimmer@sgi.com> wrote:
>> In general rwlocks are discourged so we are moving it to use the rcu instead.
>> This does require a bit of care since the cpufreq_driver_lock protects both
>> the cpufreq_driver and the cpufreq_cpu_data array.
>> Also since many of the function pointers on cpufreq_driver may sleep when
>> called we have to grab them under the rcu_read_lock but call them after
>> rcu_read_unlock();
> Even i have started reading rcu documentation now :)
>
>> 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 | 312 +++++++++++++++++++++++++++++++++-------------
>>   1 file changed, 224 insertions(+), 88 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> @@ -255,20 +258,21 @@ 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;
>> -       unsigned long flags;
>> +       u8 flags;
> I think you can get rid of flags.
>
>>          BUG_ON(irqs_disabled());
>>
>>          if (cpufreq_disabled())
>>                  return;
>>
>> -       freqs->flags = cpufreq_driver->flags;
>>          pr_debug("notification %u of frequency transition to %u kHz\n",
>>                  state, freqs->new);
>>
>> -       read_lock_irqsave(&cpufreq_driver_lock, flags);
>> +       rcu_read_lock();
>> +       flags = rcu_dereference(cpufreq_driver)->flags;
> use freq->flags here ...
>
>>          policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
>> -       read_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +       rcu_read_unlock();
>> +       freqs->flags = flags;
>>
>>          switch (state) {
>>
>> @@ -277,7 +281,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
>>                   * which is not equal to what the cpufreq core thinks is
>>                   * "old frequency".
>>                   */
>> -               if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
>> +               if (!(flags & CPUFREQ_CONST_LOOPS)) {
> and here.
Of course.
>>                          if ((policy) && (policy->cpu == freqs->cpu) &&
>>                              (policy->cur) && (policy->cur != freqs->old)) {
>>                                  pr_debug("Warning: CPU frequency is"
>
>> @@ -742,35 +773,39 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
>> -       write_lock_irqsave(&cpufreq_driver_lock, flags);
>> +       spin_lock_irqsave(&cpufreq_driver_lock, flags);
>>          for_each_cpu(j, policy->cpus) {
>>                  per_cpu(cpufreq_cpu_data, j) = policy;
>>                  per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
>>          }
>> -       write_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +       spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +       synchronize_rcu();
> I don't think (but i can be wrong too :) ), that we need a synchronize_rcu()
> here. We need it only at places where we have updated the cpufreq_driver
> pointer.
>
> As we aren't doing any rcu specific read/update for cpufreq_cpu_data.
Good point.
I placed a similar sycnronize_rcu in cpufreq_add_policy_cpu and 
cpufreq_add_dev.
I will remove them also.


Thanks, I will respin.
Nate


WARNING: multiple messages have this Message-ID (diff)
From: Nathan Zimmer <nzimmer@sgi.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: <rjw@sisk.pl>, <cpufreq@vger.kernel.org>,
	<linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] cpufreq: Convert the cpufreq_driver_lock to use the rcu
Date: Thu, 21 Feb 2013 11:49:03 -0600	[thread overview]
Message-ID: <51265E0F.6090209@sgi.com> (raw)
In-Reply-To: <CAKohponMWRPspZF=tPN6MXoxkcjw7CK_sLnSdsKe+EDoiADvGA@mail.gmail.com>

On 02/20/2013 11:50 PM, Viresh Kumar wrote:
> On 21 February 2013 05:26, Nathan Zimmer <nzimmer@sgi.com> wrote:
>> In general rwlocks are discourged so we are moving it to use the rcu instead.
>> This does require a bit of care since the cpufreq_driver_lock protects both
>> the cpufreq_driver and the cpufreq_cpu_data array.
>> Also since many of the function pointers on cpufreq_driver may sleep when
>> called we have to grab them under the rcu_read_lock but call them after
>> rcu_read_unlock();
> Even i have started reading rcu documentation now :)
>
>> 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 | 312 +++++++++++++++++++++++++++++++++-------------
>>   1 file changed, 224 insertions(+), 88 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> @@ -255,20 +258,21 @@ 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;
>> -       unsigned long flags;
>> +       u8 flags;
> I think you can get rid of flags.
>
>>          BUG_ON(irqs_disabled());
>>
>>          if (cpufreq_disabled())
>>                  return;
>>
>> -       freqs->flags = cpufreq_driver->flags;
>>          pr_debug("notification %u of frequency transition to %u kHz\n",
>>                  state, freqs->new);
>>
>> -       read_lock_irqsave(&cpufreq_driver_lock, flags);
>> +       rcu_read_lock();
>> +       flags = rcu_dereference(cpufreq_driver)->flags;
> use freq->flags here ...
>
>>          policy = per_cpu(cpufreq_cpu_data, freqs->cpu);
>> -       read_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +       rcu_read_unlock();
>> +       freqs->flags = flags;
>>
>>          switch (state) {
>>
>> @@ -277,7 +281,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
>>                   * which is not equal to what the cpufreq core thinks is
>>                   * "old frequency".
>>                   */
>> -               if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
>> +               if (!(flags & CPUFREQ_CONST_LOOPS)) {
> and here.
Of course.
>>                          if ((policy) && (policy->cpu == freqs->cpu) &&
>>                              (policy->cur) && (policy->cur != freqs->old)) {
>>                                  pr_debug("Warning: CPU frequency is"
>
>> @@ -742,35 +773,39 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
>> -       write_lock_irqsave(&cpufreq_driver_lock, flags);
>> +       spin_lock_irqsave(&cpufreq_driver_lock, flags);
>>          for_each_cpu(j, policy->cpus) {
>>                  per_cpu(cpufreq_cpu_data, j) = policy;
>>                  per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
>>          }
>> -       write_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +       spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
>> +       synchronize_rcu();
> I don't think (but i can be wrong too :) ), that we need a synchronize_rcu()
> here. We need it only at places where we have updated the cpufreq_driver
> pointer.
>
> As we aren't doing any rcu specific read/update for cpufreq_cpu_data.
Good point.
I placed a similar sycnronize_rcu in cpufreq_add_policy_cpu and 
cpufreq_add_dev.
I will remove them also.


Thanks, I will respin.
Nate


  reply	other threads:[~2013-02-21 17:49 UTC|newest]

Thread overview: 59+ 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
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 [this message]
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-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-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 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=51265E0F.6090209@sgi.com \
    --to=nzimmer@sgi.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --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.