* remote wakeup cpufreq notifications

b3f33be79280 sched: cpufreq: enable remote sched cpufreq callbacks
2b82762d1707 intel_pstate: ignore scheduler cpufreq callbacks on remote CPUs
705a998278bb cpufreq: governor: support scheduler cpufreq callbacks on remote CPUs
9cf663d3c0ff sched: cpufreq: detect, process remote callbacks
cadb3b98bf46 sched: cpufreq: remove smp_processor_id() in remote paths
382c9676816d sched: cpufreq: always trace unchanged frequency
9281fc43de45 sched: cpufreq: extend irq work to support fast switches
eae3389a1981 sched: cpufreq: allow sugov_next_freq_shared() to be run remotely
588d905a52ff sched: create late cpufreq callback
597c2e33f29e irq_work: add irq_work_queue_on for !CONFIG_SMP
2705bf9b33c8 sched: cpufreq: add cpu to update_util_data

With Android UI and benchmarks the latency of cpufreq response to certain
scheduling events can become very critical. Currently on mainline tip,
callbacks into schedutil are only made from the scheduler if the target CPU of
the event is the same as the current CPU. This means there are certain
situations where a target CPU may not run schedutil for some time.

One testcase I wrote to show this behavior is where a task starts running on
CPU0, then a new task is also spawned on CPU0 by a task on CPU1. If the system
is configured such that new tasks should receive maximum demand initially,
this should result in CPU0 increasing frequency immediately. Because of the
above mentioned limitation though this does not occur.

I implemented this set of patches which defers the callback into schedutil if
the callback would be remote (not for a CPU in the policy of which we are
running). If there is no preemption required by the wakeup a late callback
into schedutil is made, and schedutil is modified to be able to correctly deal
with remote callbacks. If preemption does occur then the scheduler, and
schedutil, will run on the remote CPU anyway.

This series will likely not be accepted upstream due to its
invasiveness in the scheduler. The right solution I think is to revisit the
location of the hooks in the scheduler overall. Perhaps they can be made to
more strongly resemble what we had with schedfreq. Rafael seemed open to this
when I proposed it. He recently had to add another hook in the enqueue path
for his iowait series which I think is not ideal.

The JIRA for this activity is PMWG-1018.