From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux PM list <linux-pm@vger.kernel.org>,
Juri Lelli <juri.lelli@arm.com>,
Steve Muckle <steve.muckle@linaro.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Michael Turquette <mturquette@baylibre.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data
Date: Wed, 30 Mar 2016 09:40:10 +0530 [thread overview]
Message-ID: <20160330041010.GD8773@vireshk-i7> (raw)
In-Reply-To: <2253696.9jRPsKRmxz@vostro.rjw.lan>
On 29-03-16, 14:58, Rafael J. Wysocki wrote:
> On Monday, March 28, 2016 02:33:33 PM Viresh Kumar wrote:
> > Its gonna be same for all policies sharing tunables ..
>
> The value will be the same, but the cacheline won't.
Fair enough. So this information is replicated for each policy for performance
benefits. Would it make sense to add a comment for that? Its not obvious today
why we are keeping this per-policy.
> > > +static ssize_t rate_limit_us_store(struct gov_attr_set *attr_set, const char *buf,
> > > + size_t count)
> > > +{
> > > + struct sugov_tunables *tunables = to_sugov_tunables(attr_set);
> > > + struct sugov_policy *sg_policy;
> > > + unsigned int rate_limit_us;
> > > + int ret;
> > > +
> > > + ret = sscanf(buf, "%u", &rate_limit_us);
> > > + if (ret != 1)
> > > + return -EINVAL;
> > > +
> > > + tunables->rate_limit_us = rate_limit_us;
> > > +
> > > + list_for_each_entry(sg_policy, &attr_set->policy_list, tunables_hook)
> > > + sg_policy->freq_update_delay_ns = rate_limit_us * NSEC_PER_USEC;
> > > +
> > > + return count;
> > > +}
> > > +
> > > +static struct governor_attr rate_limit_us = __ATTR_RW(rate_limit_us);
> >
> > Why not reuse gov_attr_rw() ?
>
> Would it work?
Why wouldn't it? I had a look again at that and I couldn't find a reason for it
to not work. Probably I missed something.
> > > + ret = kobject_init_and_add(&tunables->attr_set.kobj, &sugov_tunables_ktype,
> > > + get_governor_parent_kobj(policy), "%s",
> > > + schedutil_gov.name);
> > > + if (!ret)
> > > + goto out;
> > > +
> > > + /* Failure, so roll back. */
> > > + policy->governor_data = NULL;
> > > + sugov_tunables_free(tunables);
> > > +
> > > + free_sg_policy:
> > > + pr_err("cpufreq: schedutil governor initialization failed (error %d)\n", ret);
> > > + sugov_policy_free(sg_policy);
> >
> > I didn't like the way we have mixed success and failure path here, just to save
> > a single line of code (unlock).
>
> I don't follow, sorry. Yes, I can do unlock/return instead of the "goto out",
> but then the goto label is still needed.
Sorry for not being clear earlier, but this what I was suggesting it to look like:
---
static int sugov_init(struct cpufreq_policy *policy)
{
struct sugov_policy *sg_policy;
struct sugov_tunables *tunables;
unsigned int lat;
int ret = 0;
/* State should be equivalent to EXIT */
if (policy->governor_data)
return -EBUSY;
sg_policy = sugov_policy_alloc(policy);
if (!sg_policy)
return -ENOMEM;
mutex_lock(&global_tunables_lock);
if (global_tunables) {
if (WARN_ON(have_governor_per_policy())) {
ret = -EINVAL;
goto free_sg_policy;
}
policy->governor_data = sg_policy;
sg_policy->tunables = global_tunables;
gov_attr_set_get(&global_tunables->attr_set, &sg_policy->tunables_hook);
mutex_unlock(&global_tunables_lock);
return 0;
}
tunables = sugov_tunables_alloc(sg_policy);
if (!tunables) {
ret = -ENOMEM;
goto free_sg_policy;
}
tunables->rate_limit_us = LATENCY_MULTIPLIER;
lat = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
if (lat)
tunables->rate_limit_us *= lat;
if (!have_governor_per_policy())
global_tunables = tunables;
policy->governor_data = sg_policy;
sg_policy->tunables = tunables;
ret = kobject_init_and_add(&tunables->attr_set.kobj, &sugov_tunables_ktype,
get_governor_parent_kobj(policy), "%s",
schedutil_gov.name);
if (!ret) {
mutex_unlock(&global_tunables_lock);
return 0;
}
/* Failure, so roll back. */
policy->governor_data = NULL;
sugov_tunables_free(tunables);
free_sg_policy:
mutex_unlock(&global_tunables_lock);
pr_err("cpufreq: schedutil governor initialization failed (error %d)\n", ret);
sugov_policy_free(sg_policy);
return ret;
---
> > Over that it does things, that aren't symmetric anymore. For example, we have
> > called sugov_policy_alloc() without locks
>
> Are you sure?
Yes.
> > and are freeing it from within locks.
>
> Both are under global_tunables_lock.
No, sugov_policy_alloc() isn't called from within locks.
> > > +static int __init sugov_module_init(void)
> > > +{
> > > + return cpufreq_register_governor(&schedutil_gov);
> > > +}
> > > +
> > > +static void __exit sugov_module_exit(void)
> > > +{
> > > + cpufreq_unregister_governor(&schedutil_gov);
> > > +}
> > > +
> > > +MODULE_AUTHOR("Rafael J. Wysocki <rafael.j.wysocki@intel.com>");
> > > +MODULE_DESCRIPTION("Utilization-based CPU frequency selection");
> > > +MODULE_LICENSE("GPL");
> >
> > Maybe a MODULE_ALIAS as well ?
>
> Sorry, I don't follow.
Oh, I was just saying that we may also want to add a MODULE_ALIAS() line here
to help auto-loading if it is built as a module?
--
viresh
next prev parent reply other threads:[~2016-03-30 4:10 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 1:44 [PATCH v6 0/7] cpufreq: schedutil governor Rafael J. Wysocki
2016-03-22 1:46 ` [PATCH v6 1/7][Resend] cpufreq: sched: Helpers to add and remove update_util hooks Rafael J. Wysocki
2016-03-28 5:31 ` Viresh Kumar
2016-03-31 12:47 ` Peter Zijlstra
2016-03-22 1:47 ` [PATCH v6 2/7][Resend] cpufreq: governor: New data type for management part of dbs_data Rafael J. Wysocki
2016-03-22 1:49 ` [PATCH v6 3/7][Resend] cpufreq: governor: Move abstract gov_attr_set code to seperate file Rafael J. Wysocki
2016-03-22 1:50 ` [PATCH v6 4/7][Resend] cpufreq: Move governor attribute set headers to cpufreq.h Rafael J. Wysocki
2016-03-22 1:51 ` [PATCH v6 5/7][Resend] cpufreq: Move governor symbols " Rafael J. Wysocki
2016-03-28 5:35 ` Viresh Kumar
2016-03-22 1:53 ` [PATCH v6 6/7][Resend] cpufreq: Support for fast frequency switching Rafael J. Wysocki
2016-03-26 1:12 ` Steve Muckle
2016-03-26 1:46 ` Rafael J. Wysocki
2016-03-27 1:27 ` Rafael J. Wysocki
2016-03-28 16:47 ` Steve Muckle
2016-03-29 12:10 ` Rafael J. Wysocki
2016-03-28 6:27 ` Viresh Kumar
2016-03-29 12:31 ` Rafael J. Wysocki
2016-03-28 7:03 ` Viresh Kumar
2016-03-29 12:10 ` Rafael J. Wysocki
2016-03-29 14:20 ` Viresh Kumar
2016-03-30 1:47 ` [Update][PATCH v7 6/7] " Rafael J. Wysocki
2016-03-30 5:07 ` Viresh Kumar
2016-03-30 11:28 ` Rafael J. Wysocki
2016-03-22 1:54 ` [PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data Rafael J. Wysocki
2016-03-26 1:12 ` Steve Muckle
2016-03-26 2:05 ` Rafael J. Wysocki
2016-03-27 1:36 ` Rafael J. Wysocki
2016-03-28 18:17 ` Steve Muckle
2016-03-29 12:23 ` Rafael J. Wysocki
2016-03-31 12:24 ` Peter Zijlstra
2016-03-31 12:32 ` Rafael J. Wysocki
2016-04-01 18:15 ` Steve Muckle
2016-03-28 9:03 ` Viresh Kumar
2016-03-29 12:58 ` Rafael J. Wysocki
2016-03-30 1:12 ` Rafael J. Wysocki
2016-03-31 12:28 ` Peter Zijlstra
2016-03-30 4:10 ` Viresh Kumar [this message]
2016-03-30 2:00 ` [Update][PATCH v7 7/7] " Rafael J. Wysocki
2016-03-30 5:30 ` Viresh Kumar
2016-03-30 11:31 ` Rafael J. Wysocki
2016-03-30 17:05 ` Steve Muckle
2016-03-30 17:24 ` Rafael J. Wysocki
2016-03-31 1:44 ` Steve Muckle
2016-03-31 12:12 ` Peter Zijlstra
2016-03-31 12:18 ` Rafael J. Wysocki
2016-03-31 12:42 ` Peter Zijlstra
2016-03-31 12:48 ` Peter Zijlstra
2016-04-01 17:49 ` Steve Muckle
2016-04-01 19:14 ` Rafael J. Wysocki
2016-04-01 19:23 ` Steve Muckle
2016-04-01 23:06 ` [Update][PATCH v8 " Rafael J. Wysocki
2016-04-02 1:09 ` Steve Muckle
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=20160330041010.GD8773@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=juri.lelli@arm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mturquette@baylibre.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=steve.muckle@linaro.org \
--cc=vincent.guittot@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.