Re: [PATCH v2] sched/stats: Fix run_delay over-count for migrated sched_delayed tasks

[Kayra Cizmeci]

Hi Wei,

> Load balance is affected too: the sched_delayed check in can_migrate_task()
> bails out only when env->migration_type != migrate_load, so it does not
> block migration when the type is migrate_load - which active load balance
> always uses (its lb_env leaves migration_type at 0 == migrate_load), and
> which regular load balance can also use via calculate_imbalance(). Either
> way the re-attach goes through attach_task() -> activate_task(rq, p,
> ENQUEUE_NOCLOCK), without ENQUEUE_RESTORE.

> @@ -290,7 +290,7 @@ static void sched_info_arrive(struct rq *rq, struct task_struct *t)
>   */
>  static inline void sched_info_enqueue(struct rq *rq, struct task_struct *t)
>  {
> -	if (!t->sched_info.last_queued)
> +	if (!t->sched_info.last_queued && !t->se.sched_delayed)
>  		t->sched_info.last_queued = rq_clock(rq);
>  }

Well sched_info_enqueue() gets called from 2 places. The comment above says
otherwise but it's wrong. It gets called from sched_info_depart() and
enqueue_task().

I'll send a patch about that comment later. 

Anyway,

Let's say detach_one_task() found the p to detach on active_load_balance_cpu_stop(),
from there, p goes to attach_task() from there. And then 
activate_task(), therefore enqueue_task() and
sched_info_enqueue().

If p is delayed then, correctly the sched_info_enqueue() will not start the clock.
If not, it will. 

On the second call chain tho, there are task_is_running protection before entering sched_info_enqueue(),
therefore a task cannot run if it is delayed. So the patch's case never runs on that path. 

Here:
Reviewed-by: Kayra Cizmeci <kayracizmeci@xxxxxxxxx>


Thanks,
Kayra :>