Re: [PATCH v2 10/12] sched/fair: Reflow pick_task_fair() / newidle

[Tejun Heo]

Hello,

On Sat, Nov 07, 2026 at 12:59:23PM +0100, Peter Zijlstra wrote:
>  again:
> -	if (!cfs_rq->h_nr_queued)
> -		goto idle;
> +	if (unlikely(!cfs_rq->h_nr_queued)) {
> +		rq_modified_begin(rq, &fair_sched_class);
> +		sched_balance_newidle(rq, rf);

pick_next_task() clears rq->core->core_cookie at restart: and sets it
again only after all the siblings are picked. As newidle can now drop
the core lock in between, another sibling can see the temporary zero
and take the !need_sync fast path while a cookied task is still running
on the core. This is another SMT>2 problem:

  CPU3 is running Y, core_cookie == Y's cookie
  CPU0 pick_next_task(), core_cookie = 0
       pick_task(rq_i), newidle drops the core lock
  CPU1 pick_next_task(), core_cookie == 0 so !need_sync
       picks uncookied Z and switches to it
  CPU0 relocks and restarts as core_task_seq moved

Z and Y share the core until CPU0's selection completes and its IPIs
land. On an SMT4 VM, this triggers a couple of times per second under
core-sched churn. Maybe core_cookie can be left alone at restart: so
that it keeps its previous value until the new one is set after the
loop?

Also, core-sched churn now triggers assert_clock_updated() from
__schedule(), set_next_task_fair(), update_load_avg() and so on. While
the lock is dropped for newidle, another CPU's double_lock_balance() or
double_rq_lock() on one of the core's rqs goes through
double_rq_clock_clear_update(), which clears RQCF_UPDATED regardless of
core_pick_in_flight. If the selection doesn't restart, it goes on with
an rq which it already updated now marked as not updated. Maybe
double_rq_clock_clear_update() should follow __rq_clock_clear()?

Thanks.

--
tejun