On 19/01/16 16:30, Peter Zijlstra wrote:

On Tue, Jan 19, 2016 at 02:42:33PM +0000, Juri Lelli wrote:

quoted

On 19/01/16 15:00, Peter Zijlstra wrote:

quoted

On Wed, Jan 13, 2016 at 10:21:31AM -0800, Michael Turquette wrote:

quoted

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.

quoted

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