Messages in this thread Patch in this message |  | | From | Joonwoo Park <> | Subject | [PATCH 1/2] sched/fair: rearm hrtick timer when it's senseful | Date | Tue, 18 Oct 2016 18:41:18 -0700 |
| |
When a new cfs task enqueued, fair scheduler rearms current cfs task's hrtick expiration time with decreased slice. But the slice stops decreasing eventually when it reached sched_min_granularity. Consequently cfs scheduler also stops rearming of hrtick timer because hrtick expiration time for the current cfs task doesn't change. This is a legitimate optimization but there is a subtle error in the 'if' condition so at present cfs scheduler stops rearming of hrtick timer earlier than ideal that will cause a subtle unfairness.
When sched_latency = 6ms, sched_min_granularity = 0.75ms, sched_nr_latency = 8 :
nr_run slice period 1 6.00 ms 6 ms 2 3.00 ms 6 ms 3 4.50 ms 6 ms 4 1.50 ms 6 ms 5 1.20 ms 6 ms 6 1.00 ms 6 ms 7 0.85 ms 6 ms 8 0.75 ms 6 ms 9+ 0.75 ms 6.75ms
The first time when sched_slice becomes equal to sched_min_granularity is when cfs_rq's nr_running becomes equal to sched_nr_latency. Fix the condition to rearm the hrtick nr_running up to sched_nr_latency.
Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org> --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 71c08a8..f465448 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4507,7 +4507,7 @@ static void hrtick_update(struct rq *rq) if (!hrtick_enabled(rq) || curr->sched_class != &fair_sched_class) return; - if (cfs_rq_of(&curr->se)->nr_running < sched_nr_latency) + if (cfs_rq_of(&curr->se)->nr_running <= sched_nr_latency) hrtick_start_fair(rq, curr); } #else /* !CONFIG_SCHED_HRTICK */ -- 2.9.3
|  |