Re: [PATCH] sched_ext: introduce cpu tick

[liuwenfang]

Thanks for your feedback.

Another one issue is that if a runnable local SCX task has p->nr_cpus_allowed equal to 1,
and there are RT tasks on this CPU's runqueue, we need a chance to let BPF scheduler to adjust RT 
throttle param properly(or other methods), so that the local boud SCX task will be scheduled
in time. This is important for the mobile scenario to render smoothly at 120 frames per second.
scx_bpf_reenqueue_local will not work for the local SCX when p->nr_cpus_allowed == 1.

Also some tradeoff methods can be taken to balance the performance:
If the running SCX task is preempted by one short-running RT task(predicted by its history),
then it is better for the BPF scheduler to keep this SCX task on its local dsq, rather than directly calling
scx_bpf_reenqueue_local(). However, we still need protection for this situation in case the
short RT task become long-running task(perhaps due to some exception).

Any suggestions and comments are welcome!

Best regards

> 
> Hello,
> 
> On Tue, Jun 10, 2025 at 08:59:45AM +0000, liuwenfang wrote:
> > Assume one CPU is running one RT task and one runnable scx task on its
> > local dsq, the scx task cannot be scheduled until RT task enters
> > sleep, if RT task will run for 100ms, the scx task should be migrated
> > to other dsqs, then it can have a chance to be scheduled by other CPUs.
> >
> > So cpu_tick is added to notitfy BPF scheduler to check long runnable
> > scx on its local dsq, related policy can be taken to improve the
> > performance.
> 
> (cc'ing Kumar as we discussed similar issue recently)
> 
> There are some race conditions we need to address but calling
> scx_bpf_reenqueue_local() from ops.cpu_release() is the intended way of
> handling these situations. I don't think periodically polling from ticks is a good
> approach, especially given that ticks can be skipped w/ nohz_full.
> 
> Thanks.
> 
> --
> tejun