From: Quentin Perret <qperret@google.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Arnd Bergmann <arnd@arndb.de>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
"Cc: Android Kernel" <kernel-team@android.com>,
Todd Kjos <tkjos@google.com>,
adharmap@codeaurora.org
Subject: Re: [PATCH v2 2/2] cpufreq: Specify default governor on command line
Date: Thu, 25 Jun 2020 14:49:53 +0100 [thread overview]
Message-ID: <20200625134953.GA242742@google.com> (raw)
In-Reply-To: <CAJZ5v0jQkeu5dJXxXN2eQ+cAwv8oSK_wZZgTW3cvMZX0ks9jHQ@mail.gmail.com>
On Thursday 25 Jun 2020 at 15:28:43 (+0200), Rafael J. Wysocki wrote:
> On Thu, Jun 25, 2020 at 1:53 PM Quentin Perret <qperret@google.com> wrote:
> >
> > On Thursday 25 Jun 2020 at 13:44:34 (+0200), Rafael J. Wysocki wrote:
> > > On Thu, Jun 25, 2020 at 1:36 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > > This change is not right IMO. This part handles the set-policy case,
> > > > where there are no governors. Right now this code, for some reasons
> > > > unknown to me, forcefully uses the default governor set to indicate
> > > > the policy, which is not a great idea in my opinion TBH. This doesn't
> > > > and shouldn't care about governor modules and should only be looking
> > > > at strings instead of governor pointer.
> > >
> > > Sounds right.
> > >
> > > > Rafael, I even think we should remove this code completely and just
> > > > rely on what the driver has sent to us. Using the selected governor
> > > > for set policy drivers is very confusing and also we shouldn't be
> > > > forced to compiling any governor for the set-policy case.
> > >
> > > Well, AFAICS the idea was to use the default governor as a kind of
> > > default policy proxy, but I agree that strings should be sufficient
> > > for that.
> >
> > I agree with all the above. I'd much rather not rely on the default
> > governor name to populate the default policy, too, so +1 from me.
>
> So before this series the default governor was selected at the kernel
> configuration time (pre-build) and was always built-in. Because it
> could not go away, its name could be used to indicate the default
> policy for the "setpolicy" drivers.
>
> After this series, however, it cannot be used this way reliably, but
> you can still pass cpufreq_param_governor to cpufreq_parse_policy()
> instead of def_gov->name in cpufreq_init_policy(), can't you?
Good point. I also need to fallback to the default builtin governor if
the command line parameter isn't valid (or non-existent), so perhaps
something like so?
iff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index dad6b85f4c89..20a2020abf88 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -653,6 +653,23 @@ static unsigned int cpufreq_parse_policy(char *str_governor)
return CPUFREQ_POLICY_UNKNOWN;
}
+static unsigned int cpufreq_default_policy(void)
+{
+ unsigned int pol;
+
+ pol = cpufreq_parse_policy(cpufreq_param_governor);
+ if (pol != CPUFREQ_POLICY_UNKNOWN)
+ return pol;
+
+ if (IS_BUILTIN(CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE))
+ return CPUFREQ_POLICY_PERFORMANCE;
+
+ if (IS_BUILTIN(CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE))
+ return CPUFREQ_POLICY_POWERSAVE;
+
+ return CPUFREQ_POLICY_UNKNOWN;
+}
+
/**
* cpufreq_parse_governor - parse a governor string only for has_target()
* @str_governor: Governor name.
@@ -1085,8 +1102,8 @@ static int cpufreq_init_policy(struct cpufreq_policy *policy)
/* Use the default policy if there is no last_policy. */
if (policy->last_policy) {
pol = policy->last_policy;
- } else if (default_governor) {
- pol = cpufreq_parse_policy(default_governor->name);
+ } else {
+ pol = cpufreq_default_policy();
/*
* In case the default governor is neiter "performance"
* nor "powersave", fall back to the initial policy
WARNING: multiple messages have this Message-ID (diff)
From: Quentin Perret <qperret@google.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Juri Lelli <juri.lelli@redhat.com>,
"Cc: Android Kernel" <kernel-team@android.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
Linux PM <linux-pm@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
adharmap@codeaurora.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Todd Kjos <tkjos@google.com>
Subject: Re: [PATCH v2 2/2] cpufreq: Specify default governor on command line
Date: Thu, 25 Jun 2020 14:49:53 +0100 [thread overview]
Message-ID: <20200625134953.GA242742@google.com> (raw)
In-Reply-To: <CAJZ5v0jQkeu5dJXxXN2eQ+cAwv8oSK_wZZgTW3cvMZX0ks9jHQ@mail.gmail.com>
On Thursday 25 Jun 2020 at 15:28:43 (+0200), Rafael J. Wysocki wrote:
> On Thu, Jun 25, 2020 at 1:53 PM Quentin Perret <qperret@google.com> wrote:
> >
> > On Thursday 25 Jun 2020 at 13:44:34 (+0200), Rafael J. Wysocki wrote:
> > > On Thu, Jun 25, 2020 at 1:36 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > > This change is not right IMO. This part handles the set-policy case,
> > > > where there are no governors. Right now this code, for some reasons
> > > > unknown to me, forcefully uses the default governor set to indicate
> > > > the policy, which is not a great idea in my opinion TBH. This doesn't
> > > > and shouldn't care about governor modules and should only be looking
> > > > at strings instead of governor pointer.
> > >
> > > Sounds right.
> > >
> > > > Rafael, I even think we should remove this code completely and just
> > > > rely on what the driver has sent to us. Using the selected governor
> > > > for set policy drivers is very confusing and also we shouldn't be
> > > > forced to compiling any governor for the set-policy case.
> > >
> > > Well, AFAICS the idea was to use the default governor as a kind of
> > > default policy proxy, but I agree that strings should be sufficient
> > > for that.
> >
> > I agree with all the above. I'd much rather not rely on the default
> > governor name to populate the default policy, too, so +1 from me.
>
> So before this series the default governor was selected at the kernel
> configuration time (pre-build) and was always built-in. Because it
> could not go away, its name could be used to indicate the default
> policy for the "setpolicy" drivers.
>
> After this series, however, it cannot be used this way reliably, but
> you can still pass cpufreq_param_governor to cpufreq_parse_policy()
> instead of def_gov->name in cpufreq_init_policy(), can't you?
Good point. I also need to fallback to the default builtin governor if
the command line parameter isn't valid (or non-existent), so perhaps
something like so?
iff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index dad6b85f4c89..20a2020abf88 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -653,6 +653,23 @@ static unsigned int cpufreq_parse_policy(char *str_governor)
return CPUFREQ_POLICY_UNKNOWN;
}
+static unsigned int cpufreq_default_policy(void)
+{
+ unsigned int pol;
+
+ pol = cpufreq_parse_policy(cpufreq_param_governor);
+ if (pol != CPUFREQ_POLICY_UNKNOWN)
+ return pol;
+
+ if (IS_BUILTIN(CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE))
+ return CPUFREQ_POLICY_PERFORMANCE;
+
+ if (IS_BUILTIN(CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE))
+ return CPUFREQ_POLICY_POWERSAVE;
+
+ return CPUFREQ_POLICY_UNKNOWN;
+}
+
/**
* cpufreq_parse_governor - parse a governor string only for has_target()
* @str_governor: Governor name.
@@ -1085,8 +1102,8 @@ static int cpufreq_init_policy(struct cpufreq_policy *policy)
/* Use the default policy if there is no last_policy. */
if (policy->last_policy) {
pol = policy->last_policy;
- } else if (default_governor) {
- pol = cpufreq_parse_policy(default_governor->name);
+ } else {
+ pol = cpufreq_default_policy();
/*
* In case the default governor is neiter "performance"
* nor "powersave", fall back to the initial policy
next prev parent reply other threads:[~2020-06-25 13:50 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 14:21 [PATCH v2 0/2] cpufreq: Specify the default governor on command line Quentin Perret
2020-06-23 14:21 ` Quentin Perret
2020-06-23 14:21 ` [PATCH v2 1/2] cpufreq: Register governors at core_initcall Quentin Perret
2020-06-23 14:21 ` Quentin Perret
2020-06-23 14:21 ` [PATCH v2 2/2] cpufreq: Specify default governor on command line Quentin Perret
2020-06-23 14:21 ` Quentin Perret
2020-06-24 5:50 ` Viresh Kumar
2020-06-24 5:50 ` Viresh Kumar
2020-06-24 12:51 ` Rafael J. Wysocki
2020-06-24 12:51 ` Rafael J. Wysocki
2020-06-24 15:32 ` Quentin Perret
2020-06-24 15:32 ` Quentin Perret
2020-06-25 8:50 ` Viresh Kumar
2020-06-25 8:50 ` Viresh Kumar
2020-06-25 10:52 ` Rafael J. Wysocki
2020-06-25 10:52 ` Rafael J. Wysocki
2020-06-25 11:36 ` Viresh Kumar
2020-06-25 11:36 ` Viresh Kumar
2020-06-25 11:44 ` Rafael J. Wysocki
2020-06-25 11:44 ` Rafael J. Wysocki
2020-06-25 11:53 ` Quentin Perret
2020-06-25 11:53 ` Quentin Perret
2020-06-25 13:28 ` Rafael J. Wysocki
2020-06-25 13:28 ` Rafael J. Wysocki
2020-06-25 13:49 ` Quentin Perret [this message]
2020-06-25 13:49 ` Quentin Perret
2020-06-25 14:08 ` Rafael J. Wysocki
2020-06-25 14:08 ` Rafael J. Wysocki
2020-06-26 2:53 ` Viresh Kumar
2020-06-26 2:53 ` Viresh Kumar
2020-06-26 8:09 ` Quentin Perret
2020-06-26 8:09 ` Quentin Perret
2020-06-23 17:54 ` [PATCH v2 0/2] cpufreq: Specify the " Doug Smythies
2020-06-23 17:54 ` Doug Smythies
2020-06-23 18:04 ` Quentin Perret
2020-06-23 18:04 ` Quentin Perret
2020-06-24 0:07 ` Doug Smythies
2020-06-24 0:07 ` Doug Smythies
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=20200625134953.GA242742@google.com \
--to=qperret@google.com \
--cc=adharmap@codeaurora.org \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tkjos@google.com \
--cc=vincent.guittot@linaro.org \
--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.