From: Viresh Kumar <viresh.kumar@linaro.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
Radim Krcmar <rkrcmar@redhat.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [patch 1/3] cpufreq: implement min/max/up/down functions
Date: Fri, 3 Feb 2017 09:39:18 +0530 [thread overview]
Message-ID: <20170203040918.GJ7458@vireshk-i7> (raw)
In-Reply-To: <20170202174921.814002151@redhat.com>
On 02-02-17, 15:47, Marcelo Tosatti wrote:
> +++ kvm-pvfreq/drivers/cpufreq/cpufreq_userspace.c 2017-02-02 15:32:53.456262640 -0200
> @@ -118,6 +118,178 @@
> mutex_unlock(&userspace_mutex);
> }
>
> +static int cpufreq_is_userspace_governor(int cpu)
> +{
> + int ret;
> +
> + mutex_lock(&userspace_mutex);
> + ret = per_cpu(cpu_is_managed, cpu);
The userspace governor is buggy in the sense that cpu_is_managed is only updated
for the policy->cpu and not any other CPU in that policy. But then it was never
used with anything other than policy->cpu, so it was fine.
But now that you are allowing any CPU number here, you need to do one of these:
- Either set cpu_is_managed for all the CPUs from a policy
- Or get the policy first and pass policy->cpu here.
> + mutex_unlock(&userspace_mutex);
> +
> + return ret;
> +}
All 4 routines defined below have too much in common and it would be very easy
to write a common routine cpufreq_userspace_freq_change(), which can be called
in all the four cases. You can pass a function pointer to that, which can give
min, max, up, or down frequencies. That will make it more robust and less error
prone.
> +int cpufreq_userspace_freq_up(int cpu)
> +{
> + unsigned int curfreq, nextminfreq;
> + unsigned int ret = 0;
> + struct cpufreq_frequency_table *pos, *table;
> + struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> +
> + if (!policy)
> + return -EINVAL;
> +
> + if (!cpufreq_is_userspace_governor(cpu)) {
> + cpufreq_cpu_put(policy);
> + return -EINVAL;
> + }
Because the userspace_mutex is dropped after that routine returned, there is no
guarantee that 'cpu' is still managed by this governor. And so you need to make
sure that you drops the locks only at the end.
> +
> + cpufreq_cpu_put(policy);
This must be called only after you are done using the policy, to make sure that
the policy doesn't get freed while you are using it.
> + mutex_lock(&userspace_mutex);
> + table = policy->freq_table;
> + if (!table) {
> + mutex_unlock(&userspace_mutex);
> + return -ENODEV;
> + }
> + nextminfreq = cpufreq_quick_get_max(cpu);
Just use policy->max here, why waste time ?
> + curfreq = policy->cur;
> +
> + cpufreq_for_each_valid_entry(pos, table) {
> + if (pos->frequency > curfreq &&
> + pos->frequency < nextminfreq)
> + nextminfreq = pos->frequency;
> + }
The above part can be a routine of its own, whose pointer will be passed to
cpufreq_userspace_freq_change().
> +
> + if (nextminfreq != curfreq) {
You are missing similar checks in the last two routines, any special reason for
that ?
> + unsigned int *setspeed = policy->governor_data;
> +
> + *setspeed = nextminfreq;
> + ret = __cpufreq_driver_target(policy, nextminfreq,
> + CPUFREQ_RELATION_L);
> + } else
> + ret = 1;
Why ret 1? What are the callers expected to do on seeing this value? Maybe
return 0 as the desired freq is set by the governor ?
And always use {} for even single line code if the 'if' block has them.
> + mutex_unlock(&userspace_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(cpufreq_userspace_freq_up);
> +++ kvm-pvfreq/include/linux/cpufreq.h 2017-01-31 14:20:00.508613672 -0200
> @@ -890,4 +890,11 @@
> int cpufreq_generic_init(struct cpufreq_policy *policy,
> struct cpufreq_frequency_table *table,
> unsigned int transition_latency);
> +#ifdef CONFIG_CPU_FREQ
> +int cpufreq_userspace_freq_down(int cpu);
> +int cpufreq_userspace_freq_up(int cpu);
> +int cpufreq_userspace_freq_max(int cpu);
> +int cpufreq_userspace_freq_min(int cpu);
> +#else
Don't want to put dummy routines here? Then why the blank #else part ?
> +#endif
> #endif /* _LINUX_CPUFREQ_H */
>
--
viresh
next prev parent reply other threads:[~2017-02-03 4:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-02 17:47 [patch 0/3] KVM CPU frequency change hypercalls Marcelo Tosatti
2017-02-02 17:47 ` [patch 1/3] cpufreq: implement min/max/up/down functions Marcelo Tosatti
2017-02-03 4:09 ` Viresh Kumar [this message]
2017-02-02 17:47 ` [patch 2/3] KVM: x86: introduce ioctl to allow frequency hypercalls Marcelo Tosatti
2017-02-03 17:03 ` Radim Krcmar
2017-02-22 21:18 ` Marcelo Tosatti
2017-02-23 16:48 ` Radim Krcmar
2017-02-23 17:31 ` Paolo Bonzini
2017-02-02 17:47 ` [patch 3/3] KVM: x86: frequency change hypercalls Marcelo Tosatti
2017-02-02 18:01 ` Marcelo Tosatti
2017-02-03 17:40 ` Radim Krcmar
2017-02-03 18:24 ` Marcelo Tosatti
2017-02-03 19:28 ` Radim Krcmar
2017-02-03 12:50 ` [patch 0/3] KVM CPU " Rafael J. Wysocki
2017-02-03 16:43 ` Radim Krcmar
2017-02-03 18:14 ` Marcelo Tosatti
2017-02-03 19:09 ` Radim Krcmar
2017-02-23 17:35 ` Paolo Bonzini
2017-02-23 23:19 ` Marcelo Tosatti
2017-02-24 9:18 ` Paolo Bonzini
2017-02-24 11:50 ` Marcelo Tosatti
2017-02-24 12:17 ` Paolo Bonzini
2017-02-24 13:04 ` Marcelo Tosatti
2017-02-24 15:34 ` Paolo Bonzini
2017-02-24 16:54 ` Rafael J. Wysocki
2017-02-28 2:45 ` Marcelo Tosatti
2017-03-01 14:21 ` Paolo Bonzini
2017-03-01 15:11 ` Marcelo Tosatti
-- strict thread matches above, loose matches on Subject: below --
2017-03-01 15:04 [patch 0/3] KVM CPU frequency change hypercalls (resend) Marcelo Tosatti
2017-03-01 15:04 ` [patch 1/3] cpufreq: implement min/max/up/down functions Marcelo Tosatti
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=20170203040918.GJ7458@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=rkrcmar@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox