On Mon, Jan 23, 2017 at 3:21 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
Hi Guys,
All of this work was done by Steve before he left. I have made very minor changes, merged few patches, rebased over 4.10-rc5.
More details can be found here:
https://projects.linaro.org/browse/PMWG-1018
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 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.
Some possibly naive questions about this patch, when you say "system is configured such that new tasks should receive maximum demand", do you mean an RT task waking up on a remote CPU or do you mean in general? Can you clarify how/where this configuration for new tasks is done?
Also, if new tasks are not to receive maximum demand initially (as you indicated its configurable), then shouldn't the late cpufreq callbacks never happen for the cases where new tasks are not to receive maximum demand? With these patches they always will invoke the late callbacks? In this case the currently running task on the remote CPU should already have brought the demand levels to a high value, then in that case should the callbacks run? I was just wondering if we can avoid unwanted IPIs from this patch in that case.
Thanks!
Joel
This patchset 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.
I would be doing further testing on this to get more performance numbers with it, just wanted to get some early responses and so sending it to the EAS list.
-- viresh
Steve Muckle (9): sched: cpufreq: add cpu to update_util_data irq_work: add irq_work_queue_on for !CONFIG_SMP sched: cpufreq: extend irq work to support fast switches sched: cpufreq: remove smp_processor_id() in remote paths sched: create late cpufreq callback sched: cpufreq: detect, process remote callbacks cpufreq: governor: support scheduler cpufreq callbacks on remote CPUs intel_pstate: ignore scheduler cpufreq callbacks on remote CPUs sched: cpufreq: enable remote sched cpufreq callbacks
drivers/cpufreq/cpufreq_governor.c | 2 +- drivers/cpufreq/intel_pstate.c | 3 ++ include/linux/irq_work.h | 7 ++++ include/linux/sched.h | 1 + kernel/sched/core.c | 4 ++ kernel/sched/cpufreq.c | 1 + kernel/sched/cpufreq_schedutil.c | 80 +++++++++++++++++++++++++++----------- kernel/sched/fair.c | 6 ++- kernel/sched/sched.h | 24 +++++++++++- 9 files changed, 102 insertions(+), 26 deletions(-)
-- 2.7.1.410.g6faf27b
eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev