> >> > I wonder if you can please shed light on the case that
> >> > the dst_cpu is newly idle.
> >>
> >> The main problem if we do the test only for newly idle case, is that
> >> we are not sure to move the task because we must rely on the
> >> wakeup/sleep sequence of other tasks on an idle CPU in order to trig
> >> the migration (periodic background task as an example). So we might
> >> never move the task whereas idle CPUs are available
> >>
> > So no task is migrated in the newly idle case, if I understand the
> > above correctly.
>
> A task can be moved in both idle and newly idle. If we rely only on
> newly idle and we have only idle CPUs, we can never move task. In the
> same way, if we rely only on idle case and a CPU never stays idle long
> enough to trig the idle load balance, we will never move the task. I
> agree that for the latter, we might wonder if it's worth moving the
> task. This is your concern ?
>
I concern if the only-one cfs task is migrated to a newly-idle CPU in
your code:
+ /*
+ * The dst_cpu is idle and the src_cpu CPU has only 1 CFS task.
+ * It's worth migrating the task if the src_cpu's capacity is reduced
+ * because of other sched_class or IRQs whereas capacity stays
+ * available on dst_cpu.
+ */
+ if ((env->idle != CPU_NOT_IDLE) &&
+ (env->src_rq->cfs.h_nr_running == 1)) {
+
due to the comment:
/*
* Increment the failure counter only on periodic balance.
* We do not want newidle balance, which can be very
* frequent, pollute the failure counter causing
* excessive cache_hot migrations and active balances.
*/
if (idle != CPU_NEWLY_IDLE)
sd->nr_balance_failed++;
Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
