Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1309293

Re: [RFC PATCH 18/19] cpufreq: remove transition_lock

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

Show all headers | View raw


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 | NextPrevious in thread | Find similar | Unroll thread


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