Re: Is: Default governor regardless of cpuidle driver Was: [PATCH v2] cpuidle-haltpoll: vcpu hotplug support
On 9/2/19 10:55 PM, Rafael J. Wysocki wrote:
> On Thu, Aug 29, 2019 at 7:24 PM Marcelo Tosatti wrote:
>>
>> On Thu, Aug 29, 2019 at 06:16:05PM +0100, Joao Martins wrote:
>>> On 8/29/19 4:10 PM, Joao Martins wrote:
When cpus != maxcpus cpuidle-haltpoll will fail to register all vcpus
past the online ones and thus fail to register the idle driver.
This is because cpuidle_add_sysfs() will return with -ENODEV as a
consequence from get_cpu_device() return no device for a non-existing
CPU.
Instead switch to cpuidle_register_driver() and manually register each
of the present cpus through cpuhp_setup_state() callback and future
ones that get onlined. This mimmics similar logic that intel_idle does.
Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
Signed-off-by: Joao Martins
Signed-off-by: Boris Ostrovsky
---
>>>
>>> While testing the above, I found out another issue on the haltpoll series.
>>> But I am not sure what is best suited to cpuidle framework, hence requesting
>>> some advise if below is a reasonable solution or something else is
>>> preferred.
>>>
>>> Essentially after haltpoll governor got introduced and regardless of the
>>> cpuidle
>>> driver the default governor is gonna be haltpoll for a guest (given haltpoll
>>> governor doesn't get registered for baremetal).
>>
>> Right.
>>
>>> Right now, for a KVM guest, the
>>> idle governors have these ratings:
>>>
>>> * ladder-> 10
>>> * teo -> 19
>>> * menu -> 20
>>> * haltpoll -> 21
>>> * ladder + nohz=off -> 25
>>
>> Yes. PowerPC KVM guests crash currently due to the use of the haltpoll
>> governor (have a patch in my queue to fix this, but your solution
>> embraces more cases).
>>
>>> When a guest is booted with MWAIT and intel_idle is probed and sucessfully
>>> registered, we will end up with a haltpoll governor being used as opposed to
>>> 'menu' (which used to be the default case). This would prevent IIUC that
>>> other
>>> C-states get used other than poll_state (state 0) and state 1.
>>>
>>> Given that haltpoll governor is largely only useful with a cpuidle-haltpoll
>>> it doesn't look reasonable to be the default? What about using haltpoll
>>> governor
>>> as default when haltpoll idle driver registers or modloads.
>>>
>>> My idea to achieve the above would be to decrease the rating to 9 (before
>>> the
>>> lowest rated governor) and retain old defaults before haltpoll. Then we
>>> would
>>> allow a cpuidle driver to define a preferred governor to switch on idle
>>> driver
>>> registration. Naturally all of would be ignored if overidden by
>>> cpuidle.governor=.
>>>
>>> The diff below the scissors line is an example of that.
>>>
>>> Thoughts?
>>
>> Works for me. Rafael?
>
> It works for me too, basically, except that I would rename
> cpuidle_default_governor in the patch to cpuidle_prev_governor.
>
Great! I'll send over a series with this then (splitted accordingly).
Also, In the course of hotplug/hotunplug testing, I found two small issues with
modload/modunload -- regardless of the hotplug patch. So I am gonna add that to
the series too.
Joao
Re: Is: Default governor regardless of cpuidle driver Was: [PATCH v2] cpuidle-haltpoll: vcpu hotplug support
On Thu, Aug 29, 2019 at 7:24 PM Marcelo Tosatti wrote:
>
> On Thu, Aug 29, 2019 at 06:16:05PM +0100, Joao Martins wrote:
> > On 8/29/19 4:10 PM, Joao Martins wrote:
> > > When cpus != maxcpus cpuidle-haltpoll will fail to register all vcpus
> > > past the online ones and thus fail to register the idle driver.
> > > This is because cpuidle_add_sysfs() will return with -ENODEV as a
> > > consequence from get_cpu_device() return no device for a non-existing
> > > CPU.
> > >
> > > Instead switch to cpuidle_register_driver() and manually register each
> > > of the present cpus through cpuhp_setup_state() callback and future
> > > ones that get onlined. This mimmics similar logic that intel_idle does.
> > >
> > > Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
> > > Signed-off-by: Joao Martins
> > > Signed-off-by: Boris Ostrovsky
> > > ---
> >
> > While testing the above, I found out another issue on the haltpoll series.
> > But I am not sure what is best suited to cpuidle framework, hence requesting
> > some advise if below is a reasonable solution or something else is
> > preferred.
> >
> > Essentially after haltpoll governor got introduced and regardless of the
> > cpuidle
> > driver the default governor is gonna be haltpoll for a guest (given haltpoll
> > governor doesn't get registered for baremetal).
>
> Right.
>
> > Right now, for a KVM guest, the
> > idle governors have these ratings:
> >
> > * ladder-> 10
> > * teo -> 19
> > * menu -> 20
> > * haltpoll -> 21
> > * ladder + nohz=off -> 25
>
> Yes. PowerPC KVM guests crash currently due to the use of the haltpoll
> governor (have a patch in my queue to fix this, but your solution
> embraces more cases).
>
> > When a guest is booted with MWAIT and intel_idle is probed and sucessfully
> > registered, we will end up with a haltpoll governor being used as opposed to
> > 'menu' (which used to be the default case). This would prevent IIUC that
> > other
> > C-states get used other than poll_state (state 0) and state 1.
> >
> > Given that haltpoll governor is largely only useful with a cpuidle-haltpoll
> > it doesn't look reasonable to be the default? What about using haltpoll
> > governor
> > as default when haltpoll idle driver registers or modloads.
> >
> > My idea to achieve the above would be to decrease the rating to 9 (before
> > the
> > lowest rated governor) and retain old defaults before haltpoll. Then we
> > would
> > allow a cpuidle driver to define a preferred governor to switch on idle
> > driver
> > registration. Naturally all of would be ignored if overidden by
> > cpuidle.governor=.
> >
> > The diff below the scissors line is an example of that.
> >
> > Thoughts?
>
> Works for me. Rafael?
It works for me too, basically, except that I would rename
cpuidle_default_governor in the patch to cpuidle_prev_governor.
Re: Is: Default governor regardless of cpuidle driver Was: [PATCH v2] cpuidle-haltpoll: vcpu hotplug support
On 29/08/2019 20:07, Joao Martins wrote:
> On 8/29/19 6:42 PM, Daniel Lezcano wrote:
>> On 29/08/2019 19:16, Joao Martins wrote:
>>> On 8/29/19 4:10 PM, Joao Martins wrote:
When cpus != maxcpus cpuidle-haltpoll will fail to register all vcpus
past the online ones and thus fail to register the idle driver.
This is because cpuidle_add_sysfs() will return with -ENODEV as a
consequence from get_cpu_device() return no device for a non-existing
CPU.
Instead switch to cpuidle_register_driver() and manually register each
of the present cpus through cpuhp_setup_state() callback and future
ones that get onlined. This mimmics similar logic that intel_idle does.
Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
Signed-off-by: Joao Martins
Signed-off-by: Boris Ostrovsky
---
>>>
>>> While testing the above, I found out another issue on the haltpoll series.
>>> But I am not sure what is best suited to cpuidle framework, hence requesting
>>> some advise if below is a reasonable solution or something else is
>>> preferred.
>>>
>>> Essentially after haltpoll governor got introduced and regardless of the
>>> cpuidle
>>> driver the default governor is gonna be haltpoll for a guest (given haltpoll
>>> governor doesn't get registered for baremetal). Right now, for a KVM guest,
>>> the
>>> idle governors have these ratings:
>>>
>>> * ladder-> 10
>>> * teo -> 19
>>> * menu -> 20
>>> * haltpoll -> 21
>>> * ladder + nohz=off -> 25
>>>
>>> When a guest is booted with MWAIT and intel_idle is probed and sucessfully
>>> registered, we will end up with a haltpoll governor being used as opposed to
>>> 'menu' (which used to be the default case). This would prevent IIUC that
>>> other
>>> C-states get used other than poll_state (state 0) and state 1.
>>>
>>> Given that haltpoll governor is largely only useful with a cpuidle-haltpoll
>>> it doesn't look reasonable to be the default? What about using haltpoll
>>> governor
>>> as default when haltpoll idle driver registers or modload.
>>
>> Are the guest and host kernel the same? IOW compiled with the same
>> kernel config?
>>
> You just need to toggle this (regardless off CONFIG_HALTPOLL_CPUIDLE):
>
> CONFIG_CPU_IDLE_GOV_HALTPOLL=y
>
> And *if you are a KVM guest* it will be the default (unless using nohz=off in
> which case ladder gets the highest rating -- see the listing right above).
>
> Host will just behave differently because the haltpoll governor is checking if
> it is running as kvm guest, and only registering in that case.
I understood the problem. Actually my question was about if the kernels
are compiled for host and guest, and can be run indifferently. In this
case a runtime detection must be done as you propose, otherwise that can
be done at config time. I pretty sure it is the former but before
thinking about the runtime side, I wanted to double check.
>>> My idea to achieve the above would be to decrease the rating to 9 (before
>>> the
>>> lowest rated governor) and retain old defaults before haltpoll. Then we
>>> would
>>> allow a cpuidle driver to define a preferred governor to switch on idle
>>> driver
>>> registration. Naturally all of would be ignored if overidden by
>>> cpuidle.governor=.
--
Facebook |
Twitter |
Re: Is: Default governor regardless of cpuidle driver Was: [PATCH v2] cpuidle-haltpoll: vcpu hotplug support
On 8/29/19 6:42 PM, Daniel Lezcano wrote:
> On 29/08/2019 19:16, Joao Martins wrote:
>> On 8/29/19 4:10 PM, Joao Martins wrote:
>>> When cpus != maxcpus cpuidle-haltpoll will fail to register all vcpus
>>> past the online ones and thus fail to register the idle driver.
>>> This is because cpuidle_add_sysfs() will return with -ENODEV as a
>>> consequence from get_cpu_device() return no device for a non-existing
>>> CPU.
>>>
>>> Instead switch to cpuidle_register_driver() and manually register each
>>> of the present cpus through cpuhp_setup_state() callback and future
>>> ones that get onlined. This mimmics similar logic that intel_idle does.
>>>
>>> Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
>>> Signed-off-by: Joao Martins
>>> Signed-off-by: Boris Ostrovsky
>>> ---
>>
>> While testing the above, I found out another issue on the haltpoll series.
>> But I am not sure what is best suited to cpuidle framework, hence requesting
>> some advise if below is a reasonable solution or something else is preferred.
>>
>> Essentially after haltpoll governor got introduced and regardless of the
>> cpuidle
>> driver the default governor is gonna be haltpoll for a guest (given haltpoll
>> governor doesn't get registered for baremetal). Right now, for a KVM guest,
>> the
>> idle governors have these ratings:
>>
>> * ladder-> 10
>> * teo -> 19
>> * menu -> 20
>> * haltpoll -> 21
>> * ladder + nohz=off -> 25
>>
>> When a guest is booted with MWAIT and intel_idle is probed and sucessfully
>> registered, we will end up with a haltpoll governor being used as opposed to
>> 'menu' (which used to be the default case). This would prevent IIUC that
>> other
>> C-states get used other than poll_state (state 0) and state 1.
>>
>> Given that haltpoll governor is largely only useful with a cpuidle-haltpoll
>> it doesn't look reasonable to be the default? What about using haltpoll
>> governor
>> as default when haltpoll idle driver registers or modload.
>
> Are the guest and host kernel the same? IOW compiled with the same
> kernel config?
>
You just need to toggle this (regardless off CONFIG_HALTPOLL_CPUIDLE):
CONFIG_CPU_IDLE_GOV_HALTPOLL=y
And *if you are a KVM guest* it will be the default (unless using nohz=off in
which case ladder gets the highest rating -- see the listing right above).
Host will just behave differently because the haltpoll governor is checking if
it is running as kvm guest, and only registering in that case.
>
>> My idea to achieve the above would be to decrease the rating to 9 (before the
>> lowest rated governor) and retain old defaults before haltpoll. Then we would
>> allow a cpuidle driver to define a preferred governor to switch on idle
>> driver
>> registration. Naturally all of would be ignored if overidden by
>> cpuidle.governor=.
>>
>
>
>
>
Re: Is: Default governor regardless of cpuidle driver Was: [PATCH v2] cpuidle-haltpoll: vcpu hotplug support
On 29/08/2019 19:16, Joao Martins wrote:
> On 8/29/19 4:10 PM, Joao Martins wrote:
>> When cpus != maxcpus cpuidle-haltpoll will fail to register all vcpus
>> past the online ones and thus fail to register the idle driver.
>> This is because cpuidle_add_sysfs() will return with -ENODEV as a
>> consequence from get_cpu_device() return no device for a non-existing
>> CPU.
>>
>> Instead switch to cpuidle_register_driver() and manually register each
>> of the present cpus through cpuhp_setup_state() callback and future
>> ones that get onlined. This mimmics similar logic that intel_idle does.
>>
>> Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
>> Signed-off-by: Joao Martins
>> Signed-off-by: Boris Ostrovsky
>> ---
>
> While testing the above, I found out another issue on the haltpoll series.
> But I am not sure what is best suited to cpuidle framework, hence requesting
> some advise if below is a reasonable solution or something else is preferred.
>
> Essentially after haltpoll governor got introduced and regardless of the
> cpuidle
> driver the default governor is gonna be haltpoll for a guest (given haltpoll
> governor doesn't get registered for baremetal). Right now, for a KVM guest,
> the
> idle governors have these ratings:
>
> * ladder-> 10
> * teo -> 19
> * menu -> 20
> * haltpoll -> 21
> * ladder + nohz=off -> 25
>
> When a guest is booted with MWAIT and intel_idle is probed and sucessfully
> registered, we will end up with a haltpoll governor being used as opposed to
> 'menu' (which used to be the default case). This would prevent IIUC that other
> C-states get used other than poll_state (state 0) and state 1.
>
> Given that haltpoll governor is largely only useful with a cpuidle-haltpoll
> it doesn't look reasonable to be the default? What about using haltpoll
> governor
> as default when haltpoll idle driver registers or modload.
Are the guest and host kernel the same? IOW compiled with the same
kernel config?
> My idea to achieve the above would be to decrease the rating to 9 (before the
> lowest rated governor) and retain old defaults before haltpoll. Then we would
> allow a cpuidle driver to define a preferred governor to switch on idle driver
> registration. Naturally all of would be ignored if overidden by
> cpuidle.governor=.
>
--
Facebook |
Twitter |
Re: Is: Default governor regardless of cpuidle driver Was: [PATCH v2] cpuidle-haltpoll: vcpu hotplug support
On Thu, Aug 29, 2019 at 06:16:05PM +0100, Joao Martins wrote:
> On 8/29/19 4:10 PM, Joao Martins wrote:
> > When cpus != maxcpus cpuidle-haltpoll will fail to register all vcpus
> > past the online ones and thus fail to register the idle driver.
> > This is because cpuidle_add_sysfs() will return with -ENODEV as a
> > consequence from get_cpu_device() return no device for a non-existing
> > CPU.
> >
> > Instead switch to cpuidle_register_driver() and manually register each
> > of the present cpus through cpuhp_setup_state() callback and future
> > ones that get onlined. This mimmics similar logic that intel_idle does.
> >
> > Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
> > Signed-off-by: Joao Martins
> > Signed-off-by: Boris Ostrovsky
> > ---
>
> While testing the above, I found out another issue on the haltpoll series.
> But I am not sure what is best suited to cpuidle framework, hence requesting
> some advise if below is a reasonable solution or something else is preferred.
>
> Essentially after haltpoll governor got introduced and regardless of the
> cpuidle
> driver the default governor is gonna be haltpoll for a guest (given haltpoll
> governor doesn't get registered for baremetal).
Right.
> Right now, for a KVM guest, the
> idle governors have these ratings:
>
> * ladder-> 10
> * teo -> 19
> * menu -> 20
> * haltpoll -> 21
> * ladder + nohz=off -> 25
Yes. PowerPC KVM guests crash currently due to the use of the haltpoll
governor (have a patch in my queue to fix this, but your solution
embraces more cases).
> When a guest is booted with MWAIT and intel_idle is probed and sucessfully
> registered, we will end up with a haltpoll governor being used as opposed to
> 'menu' (which used to be the default case). This would prevent IIUC that other
> C-states get used other than poll_state (state 0) and state 1.
>
> Given that haltpoll governor is largely only useful with a cpuidle-haltpoll
> it doesn't look reasonable to be the default? What about using haltpoll
> governor
> as default when haltpoll idle driver registers or modloads.
>
> My idea to achieve the above would be to decrease the rating to 9 (before the
> lowest rated governor) and retain old defaults before haltpoll. Then we would
> allow a cpuidle driver to define a preferred governor to switch on idle driver
> registration. Naturally all of would be ignored if overidden by
> cpuidle.governor=.
>
> The diff below the scissors line is an example of that.
>
> Thoughts?
Works for me. Rafael?
>
> -- >8
>
> From: Joao Martins
> Subject: [PATCH] cpuidle: switch to prefered governor on registration
>
> Signed-off-by: Joao Martins
> ---
> drivers/cpuidle/cpuidle-haltpoll.c | 1 +
> drivers/cpuidle/cpuidle.h| 1 +
> drivers/cpuidle/driver.c | 26 ++
> drivers/cpuidle/governor.c | 6 +++---
> drivers/cpuidle/governors/haltpoll.c | 2 +-
> include/linux/cpuidle.h | 3 +++
> 6 files changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle-haltpoll.c
> b/drivers/cpuidle/cpuidle-haltpoll.c
> index 8baade23f8d0..88a38c3c35e4 100644
> --- a/drivers/cpuidle/cpuidle-haltpoll.c
> +++ b/drivers/cpuidle/cpuidle-haltpoll.c
> @@ -33,6 +33,7 @@ static int default_enter_idle(struct cpuidle_device *dev,
>
> static struct cpuidle_driver haltpoll_driver = {
> .name = "haltpoll",
> + .governor = "haltpoll",
> .owner = THIS_MODULE,
> .states = {
> { /* entry 0 is for polling */ },
> diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
> index d6613101af92..c046f49c1920 100644
> --- a/drivers/cpuidle/cpuidle.h
> +++ b/drivers/cpuidle/cpuidle.h
> @@ -22,6 +22,7 @@ extern void cpuidle_install_idle_handler(void);
> extern void cpuidle_uninstall_idle_handler(void);
>
> /* governors */
> +extern struct cpuidle_governor *cpuidle_find_governor(const char *str);
> extern int cpuidle_switch_governor(struct cpuidle_governor *gov);
>
> /* sysfs */
> diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
> index dc32f34e68d9..8b8b9d89ce58 100644
> --- a/drivers/cpuidle/driver.c
> +++ b/drivers/cpuidle/driver.c
> @@ -87,6 +87,7 @@ static inline int __cpuidle_set_driver(struct
> cpuidle_driver *drv)
> #else
>
> static struct cpuidle_driver *cpuidle_curr_driver;
> +static struct cpuidle_governor *cpuidle_default_governor = NULL;
>
> /**
> * __cpuidle_get_cpu_driver - return the global cpuidle driver pointer.
> @@ -254,12 +255,25 @@ static void __cpuidle_unregister_driver(struct
> cpuidle_driver *drv)
> */
> int cpuidle_register_driver(struct cpuidle_driver *drv)
> {
> + struct cpuidle_governor *gov;
> int ret;
>
> spin_lock(&cpuidle_driver_lock);
> ret = __cpuidle_register_driver(drv);
> spin_unlock(&cpuidle_driver_lock);
>
> +
Is: Default governor regardless of cpuidle driver Was: [PATCH v2] cpuidle-haltpoll: vcpu hotplug support
On 8/29/19 4:10 PM, Joao Martins wrote:
> When cpus != maxcpus cpuidle-haltpoll will fail to register all vcpus
> past the online ones and thus fail to register the idle driver.
> This is because cpuidle_add_sysfs() will return with -ENODEV as a
> consequence from get_cpu_device() return no device for a non-existing
> CPU.
>
> Instead switch to cpuidle_register_driver() and manually register each
> of the present cpus through cpuhp_setup_state() callback and future
> ones that get onlined. This mimmics similar logic that intel_idle does.
>
> Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
> Signed-off-by: Joao Martins
> Signed-off-by: Boris Ostrovsky
> ---
While testing the above, I found out another issue on the haltpoll series.
But I am not sure what is best suited to cpuidle framework, hence requesting
some advise if below is a reasonable solution or something else is preferred.
Essentially after haltpoll governor got introduced and regardless of the cpuidle
driver the default governor is gonna be haltpoll for a guest (given haltpoll
governor doesn't get registered for baremetal). Right now, for a KVM guest, the
idle governors have these ratings:
* ladder-> 10
* teo -> 19
* menu -> 20
* haltpoll -> 21
* ladder + nohz=off -> 25
When a guest is booted with MWAIT and intel_idle is probed and sucessfully
registered, we will end up with a haltpoll governor being used as opposed to
'menu' (which used to be the default case). This would prevent IIUC that other
C-states get used other than poll_state (state 0) and state 1.
Given that haltpoll governor is largely only useful with a cpuidle-haltpoll
it doesn't look reasonable to be the default? What about using haltpoll governor
as default when haltpoll idle driver registers or modloads.
My idea to achieve the above would be to decrease the rating to 9 (before the
lowest rated governor) and retain old defaults before haltpoll. Then we would
allow a cpuidle driver to define a preferred governor to switch on idle driver
registration. Naturally all of would be ignored if overidden by
cpuidle.governor=.
The diff below the scissors line is an example of that.
Thoughts?
-- >8
From: Joao Martins
Subject: [PATCH] cpuidle: switch to prefered governor on registration
Signed-off-by: Joao Martins
---
drivers/cpuidle/cpuidle-haltpoll.c | 1 +
drivers/cpuidle/cpuidle.h| 1 +
drivers/cpuidle/driver.c | 26 ++
drivers/cpuidle/governor.c | 6 +++---
drivers/cpuidle/governors/haltpoll.c | 2 +-
include/linux/cpuidle.h | 3 +++
6 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-haltpoll.c
b/drivers/cpuidle/cpuidle-haltpoll.c
index 8baade23f8d0..88a38c3c35e4 100644
--- a/drivers/cpuidle/cpuidle-haltpoll.c
+++ b/drivers/cpuidle/cpuidle-haltpoll.c
@@ -33,6 +33,7 @@ static int default_enter_idle(struct cpuidle_device *dev,
static struct cpuidle_driver haltpoll_driver = {
.name = "haltpoll",
+ .governor = "haltpoll",
.owner = THIS_MODULE,
.states = {
{ /* entry 0 is for polling */ },
diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
index d6613101af92..c046f49c1920 100644
--- a/drivers/cpuidle/cpuidle.h
+++ b/drivers/cpuidle/cpuidle.h
@@ -22,6 +22,7 @@ extern void cpuidle_install_idle_handler(void);
extern void cpuidle_uninstall_idle_handler(void);
/* governors */
+extern struct cpuidle_governor *cpuidle_find_governor(const char *str);
extern int cpuidle_switch_governor(struct cpuidle_governor *gov);
/* sysfs */
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index dc32f34e68d9..8b8b9d89ce58 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -87,6 +87,7 @@ static inline int __cpuidle_set_driver(struct cpuidle_driver
*drv)
#else
static struct cpuidle_driver *cpuidle_curr_driver;
+static struct cpuidle_governor *cpuidle_default_governor = NULL;
/**
* __cpuidle_get_cpu_driver - return the global cpuidle driver pointer.
@@ -254,12 +255,25 @@ static void __cpuidle_unregister_driver(struct
cpuidle_driver *drv)
*/
int cpuidle_register_driver(struct cpuidle_driver *drv)
{
+ struct cpuidle_governor *gov;
int ret;
spin_lock(&cpuidle_driver_lock);
ret = __cpuidle_register_driver(drv);
spin_unlock(&cpuidle_driver_lock);
+ if (!ret && !strlen(param_governor) && drv->governor &&
+ (cpuidle_get_driver() == drv)) {
+ mutex_lock(&cpuidle_lock);
+ gov = cpuidle_find_governor(drv->governor);
+ if (gov) {
+ cpuidle_default_governor = cpuidle_curr_governor;
+ if (cpuidle_switch_governor(gov) < 0)
+ cpuidle_default_governor = NULL;
+ }
+ mute
