Re: [PATCH v5 1/4] sched: Dispatch task ticks for donor and execution classes

[Hui Su]

Hi Kayra,

> Wouldn't it be better to merge this patch and it's use case together?
>
> The commit message is confusing too "Scheduler ticks therefore need to
> reach both the class which owns the scheduling context and the class which
> owns the execution context." But the patch doesn't do this on it's own.

You are right that patch 1 alone does not enable useful execution-context
work in the FAIR callback: the callback is still donor-gated there, so a FAIR
callback reached only as the execution class returns without doing FAIR
scheduling work.

That is intentional. I split the series so that patch 1 is a
behavior-preserving conversion of the sched_class::task_tick() interface and
the common dispatcher:

  - patch 1: generic donor/execution callback dispatch
  - patch 2: move NUMA tick work to the execution context
  - patch 3: move cache tick work to the execution context

Keeping patch 1 donor-gated makes the API and dispatcher change independently
reviewable, while patches 2 and 3 introduce the execution-context users.

I agree that the patch 1 commit message is confusing because its opening
paragraph can read as if patch 1 itself already enables useful
execution-context tick work. I will reword it to make the preparatory nature
explicit, for example:

  This patch adds the common donor/execution task_tick() dispatcher and
  updates the callback interface. Class-specific tick work remains
  donor-owned here; subsequent patches use the new dispatch path for
  execution-context NUMA and cache work.

I would prefer to keep patch 1 separate from patch 2 for now. It keeps the
sched_class::task_tick() interface conversion and cross-class dispatcher
separate from the NUMA semantic fix, and keeps the NUMA and cache fixes as
separate changes with their own Fixes: tags. If there is a preference for
introducing the dispatcher together with its first execution-context user,
I can fold patch 2 into patch 1.

Thanks,
Hui