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

[Hui Su]

On Wed, Sep 09, 2026 at 07:43:44PM +0200, Andrea Righi wrote:
> They should be compatible soon:
> https://lore.kernel.org/r/20260831134338.1531664-1-arighi@xxxxxxxxxx/
>
> It'd be good to handle SCX donor/execution context ownership in this serie as
> well, or we can coordinate to figure out the required changes.
>
> I haven't looked at the whole patch series yet (will do soon), this is JFYI. :)

Thanks for the heads-up.

I kept task_tick_scx() explicitly donor-gated in the current local draft and
did not duplicate the donor-accounting changes from your v13 series. The common
task_tick() dispatcher invokes the donor class first and, when the execution
class differs, invokes the execution class second. If sched_ext is reached
only as the execution class for a non-EXT donor, task_tick_scx() returns
without SCX policy or slice work.

I previously applied your v13 series and an integration tree containing an
earlier revision of this five-patch series on the same base. In that
integration, the task_tick_scx() hunk was the only textual conflict I
encountered.

The current revision additionally handles retained-donor scheduling-class
transitions around sched_change_begin() and sched_change_end(). Your v13
series also changes that transition path, so I have not revalidated the
combined tree after this latest P4 change. The expected resolution still
uses task_tick(rq, queued), derives the donor from rq->donor, keeps the
explicit donor-class guard, and preserves your donor-based update_curr_scx()
and SCX proxy accounting.

That earlier combined integration tree built and booted with
CONFIG_SCHED_CLASS_EXT=y and CONFIG_SCHED_PROXY_EXEC=y. It did not provide a
stable full mixed EXT->FAIR, FAIR->EXT, EXT->EXT, and RT/DL->EXT runtime
matrix, and it predates the current P4 transition changes. I am therefore
not claiming complete runtime compatibility for the current revision.

The resolved task-tick path in the integration tree is:

  struct task_struct *donor = rq->donor;

  if (donor->sched_class != &ext_sched_class)
          return;

  update_curr_scx(rq);          /* donor-based in your series */
  SCX_CALL_OP_TASK(sch, tick, rq, donor);
  if (!donor->scx.slice)
          resched_curr(rq);

The complete conflict resolution is carried by the integration tree; this
excerpt records the donor guard retained from this series and the donor
accounting retained from yours.

Could you take a look at whether this donor-gated integration is the right
direction? If so, I will revalidate the current combined tree, carry the
result into the series, and post it as v5 after the pending runtime checks.

Thanks,
Hui