After commit 5e963f2bd465 ("sched/fair: Commit to EEVDF"), the 2 early
returns in entity_tick can be removed safely.

Signed-off-by: Peng Liang <tcx4c70@gmail.com>
---
 kernel/sched/fair.c | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index df348aa55d3c..74f72a01aad4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5322,16 +5322,8 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued)
 	 * queued ticks are scheduled to match the slice, so don't bother
 	 * validating it and just reschedule.
 	 */
-	if (queued) {
+	if (queued)
 		resched_curr(rq_of(cfs_rq));
-		return;
-	}
-	/*
-	 * don't let the period tick interfere with the hrtick preemption
-	 */
-	if (!sched_feat(DOUBLE_TICK) &&
-			hrtimer_active(&rq_of(cfs_rq)->hrtick_timer))
-		return;
 #endif
 }
 
-- 
2.41.0

On Thu, Oct 26, 2023 at 08:37:20PM +0800, Peng Liang wrote:
> After commit 5e963f2bd465 ("sched/fair: Commit to EEVDF"), the 2 early
> returns in entity_tick can be removed safely.

Right, so I still need to go through the whole hrtick thing. I suspect
there's more to clean up / fix.

For exapmle, I don't think hrtick_update() still makes sense.

As to the patch at hand, since slices are now fully controlled through
update_curr() -> update_deadline(), I suspect we can clear out more.

OTOH, we have the problem where rq-clock and wall-time are not running
at the same rate, so hrtick might come in early, so that's something to
look into.

So I don't mind this patch per-se, but I do think there's far more work
to be done here.