All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-pm@lists.linux-foundation.org, linaro-dev@lists.linaro.org,
	patches@linaro.org
Subject: Re: [PATCH] cpuidle : use percpu cpuidle in the core code
Date: Fri, 30 Mar 2012 17:29:17 +0530	[thread overview]
Message-ID: <4F75A015.2010609@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F759CDE.9060108@linaro.org>

On 03/30/2012 05:15 PM, Daniel Lezcano wrote:

> On 03/30/2012 01:25 PM, Srivatsa S. Bhat wrote:
>> On 03/30/2012 04:18 PM, Daniel Lezcano wrote:
>>
>>> The usual cpuidle initialization routines are to register the
>>> driver, then register a cpuidle device per cpu.
>>>
>>> With the device's state count default initialization with the
>>> driver's state count, the code initialization remains mostly the
>>> same in the different drivers.
>>>
>>> We can then add a new function 'cpuidle_register' where we register
>>> the driver and the devices. These devices can be defined in a global
>>> static variable in cpuidle.c. We will be able to factor out and
>>> remove a lot of duplicate lines of code.
>>>
>>> As we still have some drivers, with different initialization routines,
>>> we keep 'cpuidle_register_driver' and 'cpuidle_register_device' as low
>>> level initialization routines to do some specific operations on the
>>> cpuidle devices.
>>>
>>> Signed-off-by: Daniel Lezcano<daniel.lezcano@linaro.org>
>>> ---
>>>   drivers/cpuidle/cpuidle.c |   34 ++++++++++++++++++++++++++++++++++
>>>   include/linux/cpuidle.h   |    3 +++
>>>   2 files changed, 37 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>>> index b8a1faf..2a174e8 100644
>>> --- a/drivers/cpuidle/cpuidle.c
>>> +++ b/drivers/cpuidle/cpuidle.c
>>> @@ -23,6 +23,7 @@
>>>   #include "cpuidle.h"
>>>
>>>   DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
>>> +DEFINE_PER_CPU(struct cpuidle_device, cpuidle_device);
>>>
>>>   DEFINE_MUTEX(cpuidle_lock);
>>>   LIST_HEAD(cpuidle_detected_devices);
>>> @@ -391,6 +392,39 @@ int cpuidle_register_device(struct
>>> cpuidle_device *dev)
>>>
>>>   EXPORT_SYMBOL_GPL(cpuidle_register_device);
>>>
>>> +int cpuidle_register(struct cpuidle_driver *drv)
>>> +{
>>> +    int ret, cpu;
>>> +    struct cpuidle_device *dev;
>>> +
>>> +    ret = cpuidle_register_driver(drv);
>>> +    if (ret)
>>> +        return ret;
>>> +
>>> +    for_each_online_cpu(cpu) {
>>> +        dev =&per_cpu(cpuidle_device, cpu);
>>> +        dev->cpu = cpu;
>>> +
>>> +        ret = cpuidle_register_device(dev);
>>> +        if (ret)
>>> +            goto out_unregister;
>>> +    }
>>> +
>>
>>
>> Isn't this racy with respect to CPU hotplug?
> 
> No, I don't think so. Do you see a race ?


Well, that depends on when/where this function gets called.
This patch introduces the function. Where is the caller?

As of now, if you are calling this in boot-up code, its not racy.
However, there have been attempts to speed up boot times by trying
to online cpus in parallel with the rest of the kernel initialization[1].
In that case, unless your call is an early init call, it can race
with CPU hotplug.

[1]. https://lkml.org/lkml/2012/1/30/647

> 
>>> +out:
>>> +    return ret;
>>> +
>>> +out_unregister:
>>> +    for_each_online_cpu(cpu) {
>>> +        dev =&per_cpu(cpuidle_device, cpu);
>>> +        cpuidle_unregister_device(dev);
>>> +    }
>>> +
>>
>>
>> This could be improved I guess.. What if the registration fails
>> for the first cpu itself? Then looping over entire online cpumask
>> would be a waste of time..
> 
> Certainly in a critical section that would make sense, but for 4,8 or 16
> cpus in an initialization path at boot time... Anyway, I can add what is
> proposed in https://lkml.org/lkml/2012/3/22/143.
> 


What about servers with a lot more CPUs, like say 128 or even more? :-)

Moreover I don't see any downsides to the optimization. So should be good
to add it in any case...
 
Regards,
Srivatsa S. Bhat

> 
>> Here is a discussion on some very similar code:
>> https://lkml.org/lkml/2012/3/22/72
>> https://lkml.org/lkml/2012/3/22/143
>>
>>> +    cpuidle_unregister_driver(drv);
>>> +
>>> +    goto out;
>>> +}
>>> +EXPORT_SYMBOL_GPL(cpuidle_register);
>>> +
>>>   /**
>>>    * cpuidle_unregister_device - unregisters a CPU's idle PM feature
>>>    * @dev: the cpu
>>> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
>>> index f3ebbba..17e3d33 100644
>>> --- a/include/linux/cpuidle.h
>>> +++ b/include/linux/cpuidle.h
>>> @@ -133,6 +133,7 @@ struct cpuidle_driver {
>>>   #ifdef CONFIG_CPU_IDLE
>>>   extern void disable_cpuidle(void);
>>>   extern int cpuidle_idle_call(void);
>>> +extern int cpuidle_register(struct cpuidle_driver *drv);
>>>   extern int cpuidle_register_driver(struct cpuidle_driver *drv);
>>>   struct cpuidle_driver *cpuidle_get_driver(void);
>>>   extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
>>> @@ -150,6 +151,8 @@ extern int cpuidle_wrap_enter(struct
>>> cpuidle_device *dev,
>>>   #else
>>>   static inline void disable_cpuidle(void) { }
>>>   static inline int cpuidle_idle_call(void) { return -ENODEV; }
>>> +static inline int cpuidle_register(struct cpuidle_driver *drv)
>>> +{return -ENODEV; }
>>>   static inline int cpuidle_register_driver(struct cpuidle_driver *drv)
>>>   {return -ENODEV; }
>>>   static inline struct cpuidle_driver *cpuidle_get_driver(void)
>>> {return NULL; }
>>
>>

  reply	other threads:[~2012-03-30 11:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-30 10:48 [PATCH] cpuidle : use percpu cpuidle in the core code Daniel Lezcano
2012-03-30 11:25 ` Srivatsa S. Bhat
2012-03-30 11:45   ` Daniel Lezcano
2012-03-30 11:59     ` Srivatsa S. Bhat [this message]
2012-03-30 16:18       ` Daniel Lezcano
2012-03-31  7:45         ` Srivatsa S. Bhat
     [not found]         ` <4F75DCBE.8000309-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-05-30 21:45           ` [linux-pm] " Rob Lee

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=4F75A015.2010609@linux.vnet.ibm.com \
    --to=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=linaro-dev@lists.linaro.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=patches@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.