Hi, Here is another attempt to get some benefit out of the sched-idle policy. The previous version [1] focused on getting better power numbers and this version tries to get better performance or lower response time for the tasks.
The first patch is unchanged from v1 and accumulates information about sched-idle tasks per CPU. The second patch changes the way the target CPU is selected in the fast path. Currently, we target for an idle CPU in select_idle_sibling() to run the next task, but in case we don't find idle CPUs it is better to pick a CPU which will run the task the soonest, for performance reason. A CPU which isn't idle but has only SCHED_IDLE activity queued on it should be a good target based on this criteria as any normal fair task will most likely preempt the currently running SCHED_IDLE task immediately. In fact, choosing a SCHED_IDLE CPU shall give better results as it should be able to run the task sooner than an idle CPU (which requires to be woken up from an idle state). Basic testing is done with the help of rt-app currently to make sure the task is getting placed correctly. -- viresh Viresh Kumar (2): sched: Start tracking SCHED_IDLE tasks count in cfs_rq sched/fair: Fallback to sched-idle CPU if idle CPU isn't found kernel/sched/fair.c | 42 +++++++++++++++++++++++++++++++++--------- kernel/sched/sched.h | 2 ++ 2 files changed, 35 insertions(+), 9 deletions(-) -- 2.21.0.rc0.269.g1a574e7a288b [1] https://lore.kernel.org/lkml/cover.1543229820.git.viresh.ku...@linaro.org/
