From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Need help understanding the logic of __cpuidle_set_driver
Date: Thu, 21 Aug 2014 04:04:25 +0200 [thread overview]
Message-ID: <53F553A9.7050104@linaro.org> (raw)
In-Reply-To: <CAHu9=sOwSuw5igPp0UQWJe8fwMb_vt3PPrc1A9nK4pJB5QmXDA@mail.gmail.com>
On 08/15/2014 12:20 PM, Mohammad Merajul Islam Molla wrote:
> Hello,
>
> I was looking into the code of drivers/cpuidle/driver.c. I have some
> doubts regarding the implementation of __cpuidle_set_driver function
> when CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is defined.
>
> If CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is defined, the code for
> __cpuidle_set_driver/__cpuidle_unset_driver looks as -
>
> 39 * __cpuidle_unset_driver - unset per CPU driver variables.
> 40 * @drv: a valid pointer to a struct cpuidle_driver
> 41 *
> 42 * For each CPU in the driver's CPU mask, unset the registered
> driver per CPU
> 43 * variable. If @drv is different from the registered driver, the
> corresponding
> 44 * variable is not cleared.
> 45 */
> 46 static inline void __cpuidle_unset_driver(struct cpuidle_driver *drv)
> 47 {
> 48 int cpu;
> 49
> 50 for_each_cpu(cpu, drv->cpumask) {
> 51
> 52 if (drv != __cpuidle_get_cpu_driver(cpu))
> 53 continue;
> 54
> 55 per_cpu(cpuidle_drivers, cpu) = NULL;
> 56 }
> 57 }
> 58
> 59 /**
> 60 * __cpuidle_set_driver - set per CPU driver variables for the given driver.
> 61 * @drv: a valid pointer to a struct cpuidle_driver
> 62 *
> 63 * For each CPU in the driver's cpumask, unset the registered driver per CPU
> 64 * to @drv.
> 65 *
> 66 * Returns 0 on success, -EBUSY if the CPUs have driver(s) already.
> 67 */
> 68 static inline int __cpuidle_set_driver(struct cpuidle_driver *drv)
> 69 {
> 70 int cpu;
> 71
> 72 for_each_cpu(cpu, drv->cpumask) {
> 73
> 74 if (__cpuidle_get_cpu_driver(cpu)) {
> 75 __cpuidle_unset_driver(drv);
> 76 return -EBUSY;
> 77 }
> 78
> 79 per_cpu(cpuidle_drivers, cpu) = drv;
> 80 }
> 81
> 82 return 0;
> 83 }
>
> Apparently, the comment should be - "set/register the driver per CPU
> to @drv" instead of "unset the registered driver per CPU to @drv" in
> case of __cpuidle_set_driver.
Right, it is a typo.
> However, regarding the logic, I have a few doubts -
>
> 1. for each cpu in drv->cpumask, if there is already a driver
> registered, its calling __cpuidle_unset_driver which loops over for
> each cpu in drv->cpumask again. Isn't it unnecessary to do this nested
> calls?
It is to rollback the previous changes done in the loop.
> 2. after calling __cpuidle_unset_driver, if drv equals already
> registered driver, it sets per_cpu driver to null? Isn't it wrong when
> we are trying to set to a new driver? Why do we need to unset and make
> the driver null when we are returning EBUSY from __cpuidle_set_driver?
>
> Would it be correct and cleaner if the code is written as below -
>
> static inline int __cpuidle_set_driver(struct cpuidle_driver *drv)
> {
> int ret = -EBUSY;
> int cpu;
>
> for_each_cpu(cpu, drv->cpumask) {
> if (drv == __cpuidle_get_cpu_driver(cpu)) [if drv
> is already the registered driver, do nothing]
> continue;
>
> per_cpu(cpuidle_drivers, cpu) = drv; [if only drv !=
> already registered driver, set per_cpu driver to drv and set ret 0]
> ret = 0;
> }
>
> return ret; [only if all cpus already had drv as
> registered driver, return -EBUSY. Otherwise return 0]
> }
>
>
> Please let me know your views.
>
> --
> Thanks,
> -Meraj
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Mohammad Merajul Islam Molla <meraj.enigma@gmail.com>,
kernelnewbies <kernelnewbies@kernelnewbies.org>,
linux-pm@vger.kernel.org
Subject: Re: Need help understanding the logic of __cpuidle_set_driver
Date: Thu, 21 Aug 2014 04:04:25 +0200 [thread overview]
Message-ID: <53F553A9.7050104@linaro.org> (raw)
In-Reply-To: <CAHu9=sOwSuw5igPp0UQWJe8fwMb_vt3PPrc1A9nK4pJB5QmXDA@mail.gmail.com>
On 08/15/2014 12:20 PM, Mohammad Merajul Islam Molla wrote:
> Hello,
>
> I was looking into the code of drivers/cpuidle/driver.c. I have some
> doubts regarding the implementation of __cpuidle_set_driver function
> when CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is defined.
>
> If CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is defined, the code for
> __cpuidle_set_driver/__cpuidle_unset_driver looks as -
>
> 39 * __cpuidle_unset_driver - unset per CPU driver variables.
> 40 * @drv: a valid pointer to a struct cpuidle_driver
> 41 *
> 42 * For each CPU in the driver's CPU mask, unset the registered
> driver per CPU
> 43 * variable. If @drv is different from the registered driver, the
> corresponding
> 44 * variable is not cleared.
> 45 */
> 46 static inline void __cpuidle_unset_driver(struct cpuidle_driver *drv)
> 47 {
> 48 int cpu;
> 49
> 50 for_each_cpu(cpu, drv->cpumask) {
> 51
> 52 if (drv != __cpuidle_get_cpu_driver(cpu))
> 53 continue;
> 54
> 55 per_cpu(cpuidle_drivers, cpu) = NULL;
> 56 }
> 57 }
> 58
> 59 /**
> 60 * __cpuidle_set_driver - set per CPU driver variables for the given driver.
> 61 * @drv: a valid pointer to a struct cpuidle_driver
> 62 *
> 63 * For each CPU in the driver's cpumask, unset the registered driver per CPU
> 64 * to @drv.
> 65 *
> 66 * Returns 0 on success, -EBUSY if the CPUs have driver(s) already.
> 67 */
> 68 static inline int __cpuidle_set_driver(struct cpuidle_driver *drv)
> 69 {
> 70 int cpu;
> 71
> 72 for_each_cpu(cpu, drv->cpumask) {
> 73
> 74 if (__cpuidle_get_cpu_driver(cpu)) {
> 75 __cpuidle_unset_driver(drv);
> 76 return -EBUSY;
> 77 }
> 78
> 79 per_cpu(cpuidle_drivers, cpu) = drv;
> 80 }
> 81
> 82 return 0;
> 83 }
>
> Apparently, the comment should be - "set/register the driver per CPU
> to @drv" instead of "unset the registered driver per CPU to @drv" in
> case of __cpuidle_set_driver.
Right, it is a typo.
> However, regarding the logic, I have a few doubts -
>
> 1. for each cpu in drv->cpumask, if there is already a driver
> registered, its calling __cpuidle_unset_driver which loops over for
> each cpu in drv->cpumask again. Isn't it unnecessary to do this nested
> calls?
It is to rollback the previous changes done in the loop.
> 2. after calling __cpuidle_unset_driver, if drv equals already
> registered driver, it sets per_cpu driver to null? Isn't it wrong when
> we are trying to set to a new driver? Why do we need to unset and make
> the driver null when we are returning EBUSY from __cpuidle_set_driver?
>
> Would it be correct and cleaner if the code is written as below -
>
> static inline int __cpuidle_set_driver(struct cpuidle_driver *drv)
> {
> int ret = -EBUSY;
> int cpu;
>
> for_each_cpu(cpu, drv->cpumask) {
> if (drv == __cpuidle_get_cpu_driver(cpu)) [if drv
> is already the registered driver, do nothing]
> continue;
>
> per_cpu(cpuidle_drivers, cpu) = drv; [if only drv !=
> already registered driver, set per_cpu driver to drv and set ret 0]
> ret = 0;
> }
>
> return ret; [only if all cpus already had drv as
> registered driver, return -EBUSY. Otherwise return 0]
> }
>
>
> Please let me know your views.
>
> --
> Thanks,
> -Meraj
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2014-08-21 2:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 10:20 Need help understanding the logic of __cpuidle_set_driver Mohammad Merajul Islam Molla
2014-08-15 10:20 ` Mohammad Merajul Islam Molla
2014-08-15 12:41 ` AYAN KUMAR HALDER
2014-08-15 12:41 ` AYAN KUMAR HALDER
2014-08-16 6:13 ` Mohammad Merajul Islam Molla
2014-08-16 6:13 ` Mohammad Merajul Islam Molla
2014-08-21 2:04 ` Daniel Lezcano [this message]
2014-08-21 2:04 ` Daniel Lezcano
2014-08-22 12:06 ` AYAN KUMAR HALDER
2014-08-22 12:06 ` AYAN KUMAR HALDER
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=53F553A9.7050104@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=kernelnewbies@lists.kernelnewbies.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.