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

[Peter Zijlstra <peterz@infradead.org>]

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.