Re: [PATCH v4 3/5] sched/cache: Drive cache task tick from execution context

[Hui Su <sh_def@163.com>]

On Wed, Sep 09, 2026 at 01:03:48PM +0200, Peter Zijlstra wrote:
> The result at this point in the series is:
>
> ~ static void task_tick_fair(struct rq *rq, int queued)
>   {
> ~         struct task_struct *curr = rq->curr, *donor = rq->donor;
>
> ~         if (donor->sched_class == &fair_sched_class) {
> ~                 struct sched_entity *se = &donor->se;
>
> ~                 if (se->on_rq) {
> ~                         unsigned long weight = NICE_0_LOAD;
> ~                         struct cfs_rq *cfs_rq;
>
> +                         for_each_sched_entity(se) {
> +                                 cfs_rq = cfs_rq_of(se);
> ~                                 entity_tick(cfs_rq, se, queued);
>
> +                                 weight = __calc_prop_weight(cfs_rq, se, weight);
> +                         }
> +
> ~                         se = &donor->se;
> ~                         reweight_eevdf(cfs_rq, se, weight, se->on_rq);
> +                 }
>           }
>
>           if (queued)
>                   return;
>
> +         /* Update state owned by the execution context. */
> +         if (curr->sched_class == &fair_sched_class) {
> ~                 if (static_branch_unlikely(&sched_numa_balancing))
> ~                         task_tick_numa(rq, curr);
>
> ~                 task_tick_cache(rq, curr);
> +         }
>
> +         /* Update state owned by the scheduling context. */
> +         if (donor->sched_class == &fair_sched_class) {
> ~                 update_misfit_status(donor, rq);
> ~                 check_update_overutilized_status(task_rq(donor));
>
> ~                 task_tick_core(rq, donor);
> +         }
>   }
>
>
> And that is rather weird given how task_tick() works. Please order
> things in a single donor_class and a single curr_class block. A second
> donor_class block makes no sense.

Agreed. I reordered task_tick_fair() so the final form has a single
scheduling-context block followed by a single execution-context block.

Patch 2 moves NUMA handling into the execution block, and patch 3 moves
cache handling into that same block. Misfit, overutilized, and core
scheduling work remain in the donor block.

The resulting layout is:

  if (donor->sched_class == &fair_sched_class) {
          entity_tick();
          reweight_eevdf();
          misfit/overutilized/core(donor);
  }

  if (queued)
          return;

  if (curr->sched_class == &fair_sched_class) {
          task_tick_numa(rq, curr);
          task_tick_cache(rq, curr);
  }

This excerpt shows that there is no second donor block.

Could you take a look at whether this layout addresses your concern? If so,
I will carry it into v5 and post the updated series.

Thanks,
Hui