From: "Doug Smythies" <dsmythies@telus.net>
To: "'Hanjun Guo'" <guohanjun@huawei.com>
Cc: <linux-pm@vger.kernel.org>,
"'Daniel Lezcano'" <daniel.lezcano@linaro.org>,
"'Rafael J. Wysocki'" <rjw@rjwysocki.net>
Subject: RE: [RFC PATCH] cpuidle: Make cpuidle governor switchable to be the default behaviour
Date: Mon, 27 Apr 2020 07:41:36 -0700 [thread overview]
Message-ID: <000401d61ca1$f684f7b0$e38ee710$@net> (raw)
In-Reply-To: <06ff344e-7abf-9eb6-9664-0e9f9d8d6bc7@linaro.org>
I very much support this RFC.
I have been running only with "cpuidle_sysfs_switch" for about 2 years.
Some changes would be required for the documentation files also.
On 2020.04.27 06:37 Daniel Lezcano wrote:
> On 27/04/2020 12:17, Hanjun Guo wrote:
>> For now cpuidle governor can be switched via sysfs only when the
>> boot option "cpuidle_sysfs_switch" is passed, but it's important
>> to switch the governor to adapt to different workloads, especially
>> after TEO and haltpoll governor were introduced.
>>
>> Introduce a CONFIG option to make cpuidle governor switchable to be
>> the default behaviour, which will not break the boot option behaviour.
>>
>> Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
>> ---
>> drivers/cpuidle/Kconfig | 9 +++++++++
>> drivers/cpuidle/sysfs.c | 2 +-
>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
>> index c0aeedd..c40cb40 100644
>> --- a/drivers/cpuidle/Kconfig
>> +++ b/drivers/cpuidle/Kconfig
>> @@ -47,6 +47,15 @@ config CPU_IDLE_GOV_HALTPOLL
>> config DT_IDLE_STATES
>> bool
>>
>> +config CPU_IDLE_SWITCH_GOV_IN_DEFAULT
>> + bool "Switch the CPU idle governor via sysfs at runtime in default behaviour"
>> + help
>> + Make the CPU idle governor switchable at runtime, and make it as the
>> + default behaviour even the boot option "cpuidle_sysfs_switch" is not
>> + passed in cmdline.
>> +
>> + Say N if you unsure about this.
>
> Well I wouldn't make this optional but just remove the sysfs_switch.
Agree.
> However, there is the '_ro' suffix when the option is not set. In order
> to not break the existing tools, may be let both files co-exist and add
> in the ABI/obselete the '_ro' file as candidate for removal ?
I do not like this _ro thing, and got hit by it with turbostat one time.
Agree it should be made a candidate for removal.
next prev parent reply other threads:[~2020-04-27 14:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-27 10:17 [RFC PATCH] cpuidle: Make cpuidle governor switchable to be the default behaviour Hanjun Guo
2020-04-27 13:36 ` Daniel Lezcano
2020-04-27 14:41 ` Doug Smythies [this message]
2020-04-28 2:47 ` Hanjun Guo
2020-04-29 10:46 ` Rafael J. Wysocki
2020-04-30 7:14 ` Hanjun Guo
2020-04-28 2:42 ` Hanjun Guo
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='000401d61ca1$f684f7b0$e38ee710$@net' \
--to=dsmythies@telus.net \
--cc=daniel.lezcano@linaro.org \
--cc=guohanjun@huawei.com \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/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.