Re: [PATCH 2/2] sched/cache: Use execution context for cache task tick

[Hui Su <sh_def@163.com>]

On Wed, 2026-09-02 at 13:12 -0700, Tim Chen wrote:
> Thanks for raising this issue.
> I agree that the execution context should be handed to task_tick_cache().
>
> However, the donor may be a deadline or real time task, in which case
> task_tick_fair() is not invoked at all -- and we still need
> task_tick_cache(). Note that account_mm_sched() does run in that case,
> via update_curr_common() -> update_se(), so rq->curr's mm keeps being
> accounted while mm->sc_stat.epoch, which only task_tick_cache()
> advances, goes stale. After llc_epoch_affinity_timeout epochs
> account_mm_sched() then resets mm->sc_stat.cpu to -1 and we lose the
> preferred LLC.
>
> So maybe the check belongs one level up, in sched_tick().
> There we can test whether rq->curr -- the task actually running -- is a
> fair task, and call task_tick_cache() and task_tick_numa().
> That test is the same p->sched_class != &fair_sched_class one
> account_mm_sched() already does.
>
> sched_tick_remote() would then need the same two calls added.
> Without them, nohz_full CPUs would stop getting them at all.
>
> Tim

Thanks for the review. I agree with your analysis.

The v1 cache change only passed rq->curr to task_tick_cache() from
task_tick_fair(), which still misses the case where a fair execution task
runs on behalf of an RT or deadline donor. In that case task_tick_fair()
is not invoked, although update_curr_common() still accounts execution
runtime to rq->curr.

I have reworked the series to move task_tick_numa() and task_tick_cache()
out of task_tick_fair() and invoke them from sched_tick() when rq->curr
is a fair task. The corresponding calls are also added to
sched_tick_remote() so full-dynticks CPUs continue to receive both ticks.
The calls remain after the donor scheduling-class tick to preserve the
existing runtime-accounting order.

I tested this with a QEMU topology providing two LLCs. With an RT donor and a
fair mutex owner, the unmodified kernel did not execute the cache tick during
the proxy execution episode. With the change, task_tick_cache() was observed
with p == rq->curr while rq->donor was a different RT task. The proxy test
completed three episodes without warnings or errors.

The default build passed, as did builds with NUMA balancing and cache
scheduling disabled independently and together. I also built the affected
objects with CONFIG_NO_HZ_FULL=y.

I will send v2 with these changes.

Thanks,
Hui