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

Groups > linux.kernel > #1312360

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

Show all headers | View raw

On 19/01/16 16:30, Peter Zijlstra wrote:
> On Tue, Jan 19, 2016 at 02:42:33PM +0000, Juri Lelli wrote:
> > On 19/01/16 15:00, Peter Zijlstra wrote:
> > > On Wed, Jan 13, 2016 at 10:21:31AM -0800, Michael Turquette wrote:
> > > > RCU is absolutely not a magic bullet or elixir that lets us kick off
> > > > DVFS transitions from the schedule() context. The frequency transitions
> > > > are write-side operations, as we invariably touch struct cpufreq_policy.
> > > > This means that the read-side stuff can live in the schedule() context,
> > > > but write-side needs to be kicked out to a thread.
> > > 
> > > Why? If the state is per-cpu and acquired by RCU, updates should be no
> > > problem at all.
> > > 
> > > If you need inter-cpu state, then things get to be a little tricky
> > > though, but you can actually nest a raw_spinlock_t in there if you
> > > absolutely have to.
> > > 
> > 
> > We have at least two problems. First one is that state is per frequency
> > domain (struct cpufreq_policy) and this usually spans more than one cpu.
> > Second one is that we might need to sleep while servicing the frequency
> > transition, both because platform needs to sleep and because some paths
> > of cpufreq core use sleeping locks (yes, that might be changed as well I
> > guess).  A solution based on spinlocks only might not be usable on
> > platforms that needs to sleep, also.
> 
> Sure, if you need to actually sleep to poke the hardware you've lost and
> you do indeed need the kthread thingy.
> 

Yeah, also cpufreq relies on blocking notifiers (to name one thing). So,
it seems to me quite some things needs to be changed to make it fully
non sleeping.

> > Another thing that I was thinking of actually is that since struct
> > cpufreq_policy is updated a lot (more or less at every frequency
> > transition), is it actually suitable for RCU?
> 
> That entirely depends on how 'hard' it is to 'replace/change' the
> cpufreq policy.
> 
> Typically I envision that to be very hard and require mutexes and the
> like, in which case RCU can provide a cheap lookup and existence.
> 

Right, read path is fast, but write path still requires some sort of
locking (malloc, copy and update). So, I'm wondering if this still pays
off for a structure that gets written a lot.

> So on 'sane' hardware with per logical cpu hints you can get away
> without any locks.
> 

But maybe you are saying that there are ways we can make that work :).

Thanks,

- Juri

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-19 15:10 +0100
  Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli <juri.lelli@arm.com> - 2016-01-19 15:50 +0100
    Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-19 16:40 +0100
      Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli <juri.lelli@arm.com> - 2016-01-19 17:10 +0100
        Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-19 20:20 +0100
          Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-19 20:30 +0100
            Re: [RFC PATCH 18/19] cpufreq: remove transition_lock "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-01-19 23:00 +0100
              Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-20 18:10 +0100
                Re: [RFC PATCH 18/19] cpufreq: remove transition_lock "Rafael J. Wysocki" <rafael@kernel.org> - 2016-01-20 23:20 +0100
                Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-20 23:40 +0100
                Re: [RFC PATCH 18/19] cpufreq: remove transition_lock "Rafael J. Wysocki" <rafael@kernel.org> - 2016-01-21 00:40 +0100
            Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli <juri.lelli@arm.com> - 2016-01-20 14:00 +0100

csiph-web