Hi Leo,
On 23 June 2016 at 15:43, Leo Yan leo.yan@linaro.org wrote:
After over tipping point if there have two big tasks are packing on single CPU, these two tasks can be easily meet the condition for task_hot(). In result can_migrate_task() returns false and will _NOT_ spread task within cluster.
This patch check extra condition if source CPU has more than two runnable tasks and destination CPU is idle, then consider tasks can be more aggressively to migrate.
Signed-off-by: Leo Yan leo.yan@linaro.org
kernel/sched/fair.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7fbfd41..a6eef88 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6541,6 +6541,17 @@ int can_migrate_task(struct task_struct *p, struct lb_env *env) return 1; }
/** After over tipping point then aggressively to spread task* to CPUs if destination CPU is idle and source CPU has more than* one task is runnable.*/if (energy_aware() && env->dst_rq->rd->overutilized) {if (env->dst_rq->nr_running == 0 &&env->src_rq->nr_running >= 2)
your condition seems to say that there are 2 tasks on src_rq and its place in the function indicates that the task is not the running one If the scheduler is not allowed to migrate the task, it's just because the task has run on this cpu during the last 500us (default value). So I still consider that clearing sysctl_sched_migration_cost is a better alternative if the root cause is that the task has just started to run on this cfs_rq and you want to favor task placement more than cache hotness. sysctl_sched_migration_cost is used elsewhere in the scheduler and can prevent other opportunity to balance tasks between CPUs
return 1;}schedstat_inc(p, se.statistics.nr_failed_migrations_hot); return 0;}
1.9.1