Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1309293
| From | Juri Lelli <juri.lelli@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 18/19] cpufreq: remove transition_lock |
| Date | 2016-01-14 15:00 +0100 |
| Message-ID | <qQQBs-7RP-3@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <qQ5jb-cc-5@gated-at.bofh.it> <qQi6J-E5-7@gated-at.bofh.it> <qQng6-4bv-3@gated-at.bofh.it> <qQMHw-59v-11@gated-at.bofh.it> <qQNtU-5HN-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 14/01/16 16:02, Viresh Kumar wrote: > On 13-01-16, 10:21, Michael Turquette wrote: > > Quoting Viresh Kumar (2016-01-12 22:31:48) > > > On 12-01-16, 16:54, Michael Turquette wrote: > > > > __cpufreq_driver_target should be using a per-policy lock. > > > > > > It doesn't :) > > > > It should. > > I thought we wanted the routine doing DVFS to not sleep as it will be > called from scheduler ? > > Looks fine otherwise. But yeah, the series is still incomplete in the > sense that there is no lock today around __cpufreq_driver_target(). > I was under the impression that the purpose of having __cpufreq_driver_target() exported outside cpufreq.c was working due to the fact that users implement their own locking. That's why I put the following comment in this patch. /* * Callers must ensure proper mutual exclusion on policy (for transition_ * ongoing/transition_task handling). While holding policy->rwsem is * sufficient, other schemes might work as well (e.g., cpufreq_governor.c * holds timer_mutex while entering the path that generates transitions). */ From what I can see ondemand and conservative (via governor) seem to use timer_mutex; userspace userspace_mutex instead. Do they serve different purposes instead? How do we currently serialize operations on policy when using __cpufreq_driver_target() directly otherwise? Thanks, - Juri
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli <juri.lelli@arm.com> - 2016-01-11 18:40 +0100
Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Viresh Kumar <viresh.kumar@linaro.org> - 2016-01-12 12:30 +0100
Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Michael Turquette <mturquette@baylibre.com> - 2016-01-13 02:10 +0100
Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Viresh Kumar <viresh.kumar@linaro.org> - 2016-01-13 07:40 +0100
Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli <juri.lelli@arm.com> - 2016-01-14 10:50 +0100
Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Viresh Kumar <viresh.kumar@linaro.org> - 2016-01-14 11:40 +0100
Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli <juri.lelli@arm.com> - 2016-01-14 15:00 +0100
csiph-web