Assume HRTICK is enabled, when a task is running in its time slice,
a schedule() maybe called. For example, an IRQ(not HRTICK) may
set TIF_NEED_RESCHED to this task, and then calls schedule()
before it backs to user space.

                  slice start              slice end
                     |<---------------------->|
           ----------------------------------------------
                          ^
			  |
                       schedule()

The scheduler will first call hrtick_clear() to clear the HRTICK
in __schedule(). Then in pick_next_task_fair():
       (1) if we pick a new task, we will start the HRTICK for it
            in __set_next_task_fair(), it is okay.
       (2) if we pick the current task again, we do not start the HRTICK
           for current task.

Even when "rq->cfs.h_nr_running > 1" is true, the case (2) may still occur.
For example, we may follow the RUN_TO_PARITY.

This means the current task may run beyond its time slice:
  Since the HRTICK does not work, the preemption is lost, the other tasks
should be scheduled may have to wait for a long time.

To fix this issue, this patch starts the HRTICK even when we pick
the current task again. If "rq->cfs.h_nr_running > 1" is true, it will
start a HRTICK for it.

Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
---
 kernel/sched/fair.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c338df26d26d..c7b54eb069a6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8949,6 +8949,9 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf
 		set_next_entity(cfs_rq, se);
 
 		__set_next_task_fair(rq, p, true);
+	} else {
+		if (hrtick_enabled_fair(rq))
+			hrtick_start_fair(rq, p);
 	}
 
 	return p;
-- 
2.40.1