Messages in this thread | | | Date | Tue, 19 Jan 2016 16:01:55 +0000 | From | Juri Lelli <> | Subject | Re: [RFC PATCH 18/19] cpufreq: remove transition_lock |
| |
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
| |