[PATCH v3 0/2] sched: Fix execution-context tick handling under proxy execution

[Hui Su]

Proxy execution separates the scheduling context in rq->donor from the
execution context in rq->curr. Scheduler tick hooks which operate on
execution-context state must use rq->curr, while scheduling-context
state must continue to use the donor.

Move NUMA and cache task tick handling into a common execution-context
helper. This ensures that both hooks run when a fair task executes on
behalf of an RT or deadline donor, while the remaining fair-class tick
bookkeeping stays associated with the scheduling context.

Changes in v2 (since v1):
- Move NUMA and cache execution-context tick handling from
  task_tick_fair() to sched_tick().
- Invoke the hooks when rq->curr is a fair task, allowing them to run
  when the donor belongs to another scheduling class.
- Add the corresponding calls to sched_tick_remote() to preserve
  full-dynticks behavior.

Changes in v3 (since v2):
- Factor NUMA and cache execution-context tick handling into
  sched_tick_exec_ctx(), keeping sched_tick() and sched_tick_remote()
  in sync.
- Keep sched_tick_remote()'s existing curr-based scheduling-class
  dispatch unchanged and invoke the common helper afterward.
- Reword the NUMA rationale around execution-context state and the
  task/mm associated with the execution context, with sum_exec_runtime as
  supporting state rather than the sole reason for the change.
- Document why misfit, overutilized and core-scheduling tick handling
  remains associated with the scheduling context.
- Keep the task_tick_core() consumed-slice accounting issue discussed
  during review separate from this series.

Link: https://lore.kernel.org/r/20260903041154.2479761-1-sh_def@xxxxxxx

Tested with CONFIG_SCHED_PROXY_EXEC=y and all four NUMA/cache
configuration combinations, including W=1 scheduler object builds and
a full bzImage/modules build.  The first commit was also built
independently, and a CONFIG_NO_HZ_FULL=y kernel was built and booted.

A temporary QEMU proxy-mutex reproducer exercised both a normal FAIR
path and a FAIR execution task running on behalf of an SCHED_FIFO donor.
Using the same workload with QEMU 11.1.0 exposing two L3 domains, the
unpatched kernel did not invoke task_tick_numa() or task_tick_cache() for
the FAIR execution task during proxy execution.  With this series, both
hooks were repeatedly observed with rq->curr while rq->donor remained the
RT scheduling context.  NUMA task work was queued for the execution task;
cache work was also queued and its mm scan epoch advanced.  Three proxy
episodes completed, and the normal FAIR path was observed with
rq->curr == rq->donor.  The full-dynticks remote tick path was observed
invoking sched_tick_exec_ctx() on CPU 1.  No warnings, BUGs, oopses or
panics were observed.

The instrumentation and reproducer were kept outside this series.

Hui Su (2):
  sched/numa: Drive NUMA task tick from execution context
  sched/cache: Drive cache task tick from execution context

 kernel/sched/core.c  | 15 +++++++++++++++
 kernel/sched/fair.c  | 18 +++++++++---------
 kernel/sched/sched.h |  2 ++
 3 files changed, 26 insertions(+), 9 deletions(-)