On Thu, Apr 25, 2019 at 03:07:40PM +0530, Viresh Kumar wrote: > 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). > > This patch updates the fast path to fallback to a sched-idle CPU if the > idle CPU isn't found, the slow path can be updated separately later. > > Following is the order in which select_idle_sibling() picks up next CPU > to run the task now: > > 1. idle_cpu(target) OR sched_idle_cpu(target) > 2. idle_cpu(prev) OR sched_idle_cpu(prev) > 3. idle_cpu(recent_used_cpu) OR sched_idle_cpu(recent_used_cpu) > 4. idle core(sd) > 5. idle_cpu(sd) > 6. sched_idle_cpu(sd) > 7. idle_cpu(p) - smt > 8. sched_idle_cpu(p)- smt > > Though the policy can be tweaked a bit if we want to have different > priorities.
I don't hate his per se; but the whole select_idle_sibling() thing is something that needs looking at. There was the task stealing thing from Steve that looked interesting and that would render your apporach unfeasible.
